根本原因是未禁用干扰项，需禁用gc暂停、jit预热不足、cpu频率调整、后台进程抢占等，并显式配置memorydiagnoser、gcserver、simplejob等。
为什么 BenchmarkDotNet 测试结果波动大或不准
根本原因常是没禁用干扰项，而非代码本身。默认运行时会受 GC 暂停、JIT 预热不充分、CPU 频率动态调整、后台进程抢占等影响。BenchmarkDotNet 虽自动处理部分问题，但需显式配置才能稳定。
- 必须加
[MemoryDiagnoser]和[GcServer(true)]（.NET 6+ 推荐），否则内存分配和 GC 行为不可比 - 避免在笔记本上插电/电池模式切换中跑基准——CPU 节能策略会导致
Mean偏差超 20% - 禁用 Windows 快速启动、Hyper-V、WSL2 等虚拟化服务，它们会干扰计时精度
- 不要用
Debug配置编译——必须用Release，且确保Optimize code已勾选
BenchmarkDotNet 最小可用配置怎么写
一个真正可复现的基准测试，核心就三样：特性标记、静态方法、主入口调用。少任何一项都可能被跳过或误判为无效基准。
[SimpleJob(RuntimeMoniker.Net80)]
[MemoryDiagnoser]
public class StringConcatBenchmark
{
[Benchmark]
public string Plus() => "a" + "b" + "c";
[Benchmark]
public string StringBuilder()
{
var sb = new StringBuilder();
sb.Append("a").Append("b").Append("c");
return sb.ToString();
}
}
// 主程序中这样运行
class Program
{
static void Main(string[] args)
=> BenchmarkRunner.Run<StringConcatBenchmark>();
-
[SimpleJob]显式指定运行时，避免自动探测失败（尤其多 SDK 共存时） - 方法必须是
public、non-static或static均可，但推荐static避免实例初始化开销干扰 - 类名必须以
Benchmark结尾，否则BenchmarkRunner默认过滤掉 - 不加
[MemoryDiagnoser]就看不到Allocated列，而内存分配往往是性能瓶颈主因
如何对比不同输入规模下的性能变化
单点测试容易掩盖渐进复杂度问题。比如 string.Concat 和 StringBuilder 在长度为 3 时差距微乎其微，但到 1000 个字符串拼接时差异爆炸。
- 用
[Params(10, 100, 1000)]定义参数维度，字段名必须是public或public readonly - 不要在
[Benchmark]方法里生成测试数据——它会在每次迭代前被调用，污染测量结果 - 正确做法：用
[GlobalSetup]预生成数据，存在public字段中供各 benchmark 复用 - 慎用
[ParamsSource]——若源是 LINQ 查询或文件读取，容易引入 I/O 或延迟偏差
public class ConcatScaleBenchmark
{
public int Size { get; set; }
private string[] _strings;
[GlobalSetup]
public void Setup() => _strings = Enumerable.Repeat("x", Size).ToArray();
[Params(10, 100, 1000)]
public int Size;
[Benchmark]
public string StringJoin() => string.Join("", _strings);
[Benchmark]
public string StringBuilderLoop()
{
var sb = new StringBuilder();
foreach (var s in _strings) sb.Append(s);
return sb.ToString();
}
}
常见错误：把调试逻辑混进 benchmark 方法
加日志、断点、Console.WriteLine、异常捕获甚至 Debugger.IsAttached 判断，都会让结果完全失效——这些操作本身开销远大于被测逻辑。
-
BenchmarkDotNet运行时默认关闭控制台输出，Console.WriteLine实际被重定向到空流，但仍有锁和格式化开销 - 所有异常应提前在
[GlobalSetup]中暴露，benchmark 方法内不应有 try-catch（除非你就是在测异常处理性能） - 禁止使用
DateTime.Now或Stopwatch手动计时——这会与BenchmarkDotNet的高精度硬件计数器冲突 - 异步方法必须用
[Benchmark] public async Task<t> Method()</t>，不能返回Task后用.Wait()或.Result——同步等待会拖垮线程池并放大调度抖动
StdDev 就可能比 Mean 还大。 
