BenchmarkDotNet 默认仅在 Release 模式 + .NET 6+ 下输出可信结果；Debug 模式直接报错或失真，且需满足目标框架≥net6.0、SDK 风格项目文件、仅引用 BenchmarkDotNet 包、用 dotnet run -c Release 运行等硬性条件。
BenchmarkDotNet 不是“加个特性就能跑”的玩具库，它默认只在 Release 模式 + .NET 6+（含 JIT 预热支持）下给出可信结果；Debug 模式下直接报错或数据失真，这是绝大多数人踩的第一个坑。
安装与项目配置必须满足硬性条件
不满足以下任一条件，BenchmarkRunner.Run<T>() 要么编译失败，要么输出的 Mean 和 Allocated 完全不可信：
- 目标框架必须是
net6.0或更高（如net8.0），低版本无法启用硬件计数器和 JIT 预热 - 项目文件需为 SDK 风格（
<Project Sdk="Microsoft.NET.Sdk">），老式.csproj会缺关键 MSBuild target - NuGet 包仅需
BenchmarkDotNet，BenchmarkDotNet.Diagnostics.Windows是可选诊断扩展，非必需 - 必须用 Visual Studio 或
dotnet run -c Release运行 —— Debug 模式下BenchmarkRunner会抛InvalidOperationException: This benchmark is not supported in debug mode
[Benchmark] 方法的签名和副作用限制极严
看似简单的方法标记，实际有隐藏规则。违反任意一条，BenchmarkDotNet 会静默跳过该方法、返回空结果，或触发死码消除（Dead Code Elimination）导致时间测出接近 0ns：
- 返回类型必须是
void或具体类型（如string），但若返回值未被消费，JIT 可能直接优化掉整个调用 - 参数只能是无参，或仅接受
BenchmarkDotNet.Engines.IHost（极少用），不能带自定义参数 —— 想测不同输入规模？用[Params(100, 1000)] - 禁止在
[Benchmark]方法体内做任何初始化：不能new对象、不能读文件、不能调DateTime.Now—— 这些必须挪到[GlobalSetup]或[IterationSetup] - 若方法返回值用于后续逻辑（比如参与计算），必须确保返回值被 BenchmarkDotNet 内部捕获，否则会被优化；最稳妥写法是直接
return，不要赋值给局部变量后丢弃
MemoryDiagnoser 和 RankColumn 不是装饰，而是关键诊断开关
没加 [MemoryDiagnoser]，你根本看不到 Allocated 和 GC 代次数；没加 [RankColumn]，面对 5 个变体时无法一眼识别谁最快 —— 这两个特性不是锦上添花，是分析必选项：
-
[MemoryDiagnoser]会注入 IL 重写逻辑，在每次迭代前后抓取 GC 堆快照，没有它，Allocated列永远显示- -
[RankColumn]会按Mean自动给每行打 Rank（如 Rank-1 表示最快），避免人工比数字；配合[Baseline = true]可让其他行显示相对提速百分比 - 注意：加了
[MemoryDiagnoser]后运行时间明显变长（因要采集内存数据），这是正常现象，不是性能退化 - 别信控制台最后一行 summary 的 “Fastest” 提示 —— 它只看 Mean，不考虑 StdDev；真正稳的，是
Mean低且StdDev小（建议 StdDev / Mean < 2%）
结果里最该盯住的三个数字
报告表格密密麻麻，但日常优化只需盯死三项，其余都是干扰项：
-
Mean：主参考指标，单位通常是 ns（纳秒）。注意看是否标了ns/op（每操作）还是ns（单次调用），二者量级差百倍 -
StdDev：标准差。若 >Mean的 5%，说明环境不稳定（后台进程干扰、CPU 频率波动），需重跑；稳定压测应 < 1% -
Allocated：单次调用分配的字节数。比Mean更早暴露问题 —— 例如string.Concat比StringBuilder快，但 Allocated 高 10 倍，意味着 GC 压力大
真正难的是让 Mean 降下去的同时，不让 Allocated 翻倍；很多“优化”只是把时间成本转嫁给了 GC 线程。
