为什么 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——同步等待会拖垮线程池并放大调度抖动 实际跑出可靠数据的关键，往往不在“怎么写 benchmark”，而在于“怎么关掉一切不该开的东西”。哪怕配置全对，如果测试机同时开着 Chrome、OneDrive 和 Visual Studio 后台分析，
StdDev就可能比
Mean还大。
