benchmarkdotnet测算法性能核心是“测得准”：自动屏蔽jit预热、死码消除等干扰，mean和allocated才是真实可比硬指标；需用public类、[globalsetup]初始化、[memorydiagnoser]必启，并在目标环境release模式下运行。
直接上结论：用 BenchmarkDotNet 对比算法性能，核心不是“写得快”，而是“测得准”——它自动屏蔽 JIT 预热、死码消除、时钟抖动等干扰，Mean 和 Allocated 才是真实可比的硬指标。
怎么写一个能被正确测量的基准类
很多人的测试结果飘忽、不可复现，问题往往出在类结构和方法签名上。BenchmarkDotNet 要求非常严格：
- 测试类必须是
public，不能是internal或嵌套类 - 每个待测方法必须返回
void或具体类型（不推荐void，否则无法验证逻辑是否被优化掉） - 方法不能带参数（除非用
[Params]或IHost，但极少见） - 所有初始化操作（如构造数组、读文件、new 大对象）必须挪到
[GlobalSetup]里，否则会被计入耗时 - 避免在
[Benchmark]方法里做任何非核心逻辑，比如日志、条件判断、异常捕获
错误示例：ConcatWithPlus 方法里每次循环都 new 一个 StringBuilder，那测的其实是 GC + 构造开销，不是拼接本身。
为什么加 [MemoryDiagnoser] 不是可选，而是必须
只看执行时间（Mean）会漏掉关键瓶颈。比如两个算法耗时接近，但一个分配了 2MB 内存，另一个只分配 128B，后者在高频调用或长生命周期服务中更稳。
-
[MemoryDiagnoser]会强制启用 .NET 的 GC 分析 API，报告Allocated（单次调用字节数）、Gen0/Gen1次数 - 不加这个特性，
BenchmarkRunner默认不采集内存数据，输出里压根没有Allocated列 - 在 .NET 6+ 上，它还能识别 Span / Memory
等零分配模式，帮你确认是否真做到了“无堆分配”
注意：Windows 上需额外引用 BenchmarkDotNet.Diagnostics.Windows 包才能看到 GC 代际细节；Linux/macOS 依赖 dotnet-trace，但 Allocated 基础值仍可用。
运行时环境对结果影响有多大
同一段代码，在 .NET 6、.NET 8、x64、ARM64、Release vs Debug 下，结果可能差 2–5 倍。这不是误差，是真实差异。
- 默认情况下，
BenchmarkRunner.Run<t>()</t>只在当前 SDK 和运行时下跑一次。想跨版本对比？得显式配置：ManualConfig.Create(DefaultConfig.Instance).AddJob(Job.ShortRun.WithRuntime(CoreRuntime.Core80)) - ARM64（如 M1/M2 Mac）上，某些 SIMD 指令未启用或路径不同，
Span<char>.IndexOf</char>类方法可能比 x64 慢 15% —— 这种差异只有跨平台跑才能暴露 - Release 模式是底线。Debug 模式下 JIT 不内联、不优化、不移除死码，测出来全是噪音
别信“我本地测过没问题”。如果目标部署环境是 Ubuntu + .NET 8 ARM64，你的基准测试就必须在那里跑，而不是 Windows + .NET 6 x64。
常见误判陷阱：Mean 低 ≠ 实际更快
很多人扫一眼表格，挑 Mean 最小的就当最优解，结果上线后反而更卡。原因在于没看全三列：
-
Error太大（比如 ±50ns），说明样本波动剧烈，可能受后台 GC、系统中断干扰，这组数据不可信 -
StdDev远高于Mean（如 StdDev = 2×Mean），代表稳定性差，高并发下容易毛刺 -
Gen0高但Mean低，短期快，长期吃内存 —— 尤其在 ASP.NET Core 中，每请求都触发 Gen0 GC，累积延迟远超单次 Mean
真正可靠的对比，要同时满足：Mean 较低、Error StdDev Allocated 显著更低。缺一不可。
