benchmarkdotnet是严格遵循契约的测量系统，非简单计时器：测试类须为public非嵌套非抽象，[benchmark]方法须public无参且返回void/task，项目须sdk风格并明确targetframework，首次运行必用release模式，初始化逻辑须置于[globalsetup]，结果需综合mean、stddev与allocated分析。
BenchmarkDotNet 不是“用起来就完事”的计时器，它是一套有严格契约的测量系统。没按它的规则写，测出来的数字基本没参考价值——哪怕跑通了、输出了表格，也可能在测垃圾。
测试类和方法必须满足这三条硬性条件
不是“能编译通过就行”，而是运行时识别基准项的底层逻辑直接依赖这些约束：
-
public类：不能是internal、private或嵌套类；abstract也不行 -
[Benchmark]方法必须是public、void（或Task，但需额外加[AsyncBenchmark]属性） - 方法不能有任何参数：写成
public void Test(int n)会直接报错Method 'Test' has parameters. Only parameterless methods are supported.
常见错误现象：控制台输出 0 benchmark method(s) found 或空表格——八成是类或方法访问修饰符/签名不对。
项目配置错一个字母，构建就卡死在 “Building for .NET Core”
新版 BenchmarkDotNet（v0.13+）强制要求 SDK 风格项目，且目标框架必须显式声明。老式 .csproj 或模糊写法会导致构建失败或静默降级。
- 检查
.csproj顶部是否为：<project sdk="Microsoft.NET.Sdk"></project>（不是ToolsVersion那种） -
<targetframework></targetframework>必须明确，如net8.0或net9.0；不能写netcoreapp3.1，也不能留空 - 删掉
<outputtype>Exe</outputtype>——BenchmarkRunner自己生成宿主进程，冲突会引发构建异常 - 首次运行务必用
dotnet run -c Release：Debug 模式下 JIT 优化被禁用，BenchmarkDotNet会拒绝执行并提示Assembly ... is non-optimized
兼容性影响：若目标框架写成 net6.0 却在机器上只装了 .NET 8 SDK，dotnet --list-sdks 查不到对应版本，构建也会失败。
IO 或初始化逻辑放错位置，测的全是缓存和 GC 噪声
文件读写、对象创建、字符串解析这类操作，如果直接写在 [Benchmark] 方法里，每次迭代都会触发新分配、磁盘缓存命中、GC 扰动——结果反映的是系统调度，不是代码本身开销。
- 所有一次性准备动作（如生成测试文件、预热数据、构造大对象）必须挪到
[GlobalSetup]中 - 清理动作（如删临时文件、释放非托管资源）放在
[GlobalCleanup]，确保每轮迭代环境干净 - 避免在
[Benchmark]里调用Console.WriteLine、Debug.WriteLine、File.ReadAllText等带副作用的操作；它们会污染计时，甚至被 JIT 当作死码消除 - 对 IO 测试，建议加
[MemoryDiagnoser(disableGcTimer: true)]：默认内存诊断器会在每次迭代前强制 GC，严重干扰 IO 调度节奏
性能陷阱示例：测 File.ReadAllText vs FileStream.Read，若没用 [GlobalSetup] 统一提供文件路径，第二次迭代很可能走系统页缓存，快得离谱——但这不代表真实冷路径性能。
结果看 Mean 就够了吗？StdDev 和 Allocated 才是关键信号
Mean 是平均耗时，但它只是表象。真正暴露问题的是波动性和资源开销：
-
StdDev远大于Mean（比如 StdDev / Mean > 0.3）：说明测量不稳定，大概率受后台进程、杀毒软件、VS 调试器干扰，或方法内部存在非确定性行为（如锁竞争、随机数、未预热的 JIT） -
Allocated显著偏高：即使Mean看着快，也可能因频繁分配触发 GC，拖慢整体吞吐；尤其要注意Gen0次数，高频小对象分配是隐形杀手 -
Error列数值大：统计置信度低，可能迭代次数不够，或样本离散度过高；可加[SimpleJob(iterationCount: 15)]提升采样量
容易忽略的点：同一份代码在不同 CPU 上 Mean 差异可能达 2–3 倍，这不是 bug，而是 AVX 指令支持、分支预测器效率、L3 缓存大小等硬件差异的真实体现——所以跨机器对比时，StdDev 和相对趋势比绝对数值更有意义。
