BenchmarkDotNet不是简单加特性就能运行的计时器，而是需环境对齐、代码隔离、统计受控的基准测试系统；常见问题包括类/方法修饰符不符、项目配置错误、环境干扰及死码消除等。
BenchmarkDotNet 不是“加个特性就能跑”的计时器，它是一套需要环境对齐、代码隔离、统计受控的基准测试系统。直接在现有项目里贴个 [Benchmark] 很大概率会报错或结果失真。
为什么 [Benchmark] 方法没被识别？
最常见原因是类或方法的访问修饰符/签名不满足框架硬性要求：
- 测试类必须是
public，不能是internal、private或嵌套类（比如写在Program里） -
[Benchmark]方法必须是public、无参数、返回void（或Task，但需额外启用异步支持） - 写了
public void Test(int n)→ 直接报错：Method 'Test' has parameters. Only parameterless methods are supported. - 写了
async Task Test()但没加[Benchmark]属性或没引用BenchmarkDotNet.Diagnostics.Windows→ 方法被完全忽略
为什么运行后卡在 Building for .NET Core 或提示 Unable to locate output directory？
这是 SDK 风格项目配置缺失导致的构建失败，不是代码问题：
- 确认
.csproj顶部是 - 必须显式指定目标框架，如
net8.0 netcoreapp3.1或留空 - 删掉
Exe - 用命令行验证环境：
dotnet --list-sdks确保已安装对应版本 SDK（如 net8.0），且未被 VS 调试器附加
为什么 Mean 和 Median 差距极大，StdDev 远超 Mean？
说明测量值严重离散，不是代码慢，而是基准环境被干扰：
- 后台杀毒软件（尤其是 Windows Defender 实时防护）、Chrome、OneDrive 同步服务会随机抢占 CPU
- 测试方法里调用了
Console.WriteLine、File.ReadAllText或任何非受控 IO → 每次迭代延迟不可预测 - 对象分配不一致：没加
[MemoryDiagnoser]时看不到Gen0波动，但 GC 触发会大幅拉高单次耗时 - 解决办法：关闭所有非必要进程；把初始化逻辑（如 new 对象、读配置）移到
[GlobalSetup]；注释掉所有日志输出
如何避免“死码消除”导致结果为 0ns？
BenchmarkDotNet 会静态分析方法体，如果返回值没被消费，JIT 可能直接优化掉整段逻辑：
- 不要写
return _a + _b;然后不管 —— 改成var result = _a + _b; return result;并确保result被 BenchmarkDotNet 内部使用（它默认会捕获返回值） - 更稳妥的做法：用
[Benchmark(Description = "concat with +")]辅助验证方法是否被纳入统计 - 复杂计算建议搭配
[MemoryDiagnoser]，看Allocated列是否稳定 —— 如果某次迭代突然多分配几 MB，大概率是 GC 或 JIT 干扰了测量
真正难的从来不是写几个 [Benchmark]，而是让每次迭代都在同一片“安静的 CPU 时间片”里执行。环境不稳定，再准的算法对比也是噪声。
