Benchmark::DoNotOptimize并非万能，需配合ClobberMemory()防止计算重排或消除，且须确保结果被真正使用；手动计时破坏Google Benchmark统计模型，应使用PauseTiming()而非std::chrono；BENCHMARK_TEMPLATE易致模板爆炸，宜用constexpr if替代多特化。

为什么 Benchmark::DoNotOptimize 不是万能的

直接把待测函数包裹在 Benchmark::DoNotOptimize 里，常被误认为“防止优化就万事大吉”。实际中，编译器仍可能将整个计算提前到基准循环外（尤其是无副作用的纯函数），或把多次调用合并为一次。关键在于：该函数只阻止值被优化掉，不阻止计算本身被重排或消除。

• 必须配合 Benchmark::DoNotOptimize + Benchmark::ClobberMemory() 使用，后者强制编译器刷新寄存器和内存别名状态
• 若函数返回值参与后续逻辑（如累加），需确保结果真正被使用——例如赋给一个 volatile 变量，或传入 Benchmark::DoNotOptimize 后立即读取
• 对修改全局状态的函数（如填充 vector），还要注意 std::vector::reserve 是否被提前调用，否则内存分配开销会污染测量

如何正确设置 BENCHMARK_MAIN() 和运行参数

默认 BENCHMARK_MAIN() 会启用所有内置计时器，但某些环境（如虚拟机、容器）下 CPU 频率动态调整会导致抖动。必须显式控制基准行为，而非依赖默认。

• 通过命令行传参比硬编码更灵活：

  ./benchmark --benchmark_repetitions=5 --benchmark_report_aggregates_only=true --benchmark_format=json

• --benchmark_min_time=1 比默认的 0.5 秒更稳妥，避免短函数因计时精度不足产生噪声
• 禁用 CPU 频率缩放（Linux）：echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor，否则 ns_per_iteration 波动可能超 20%

避免 std::chrono 手动计时与 Google Benchmark 混用

有人试图在 Benchmark::State 循环内用 std::chrono::high_resolution_clock 手动测单次耗时，再除以迭代次数——这完全破坏了 Benchmark 的统计模型。Google Benchmark 不是简单取平均，它会剔除异常值、拟合置信区间、检测抖动，并自动调整迭代次数使误差低于阈值。

• 手动计时绕过了 Benchmark::State::PauseTiming() 和 ResumeTiming() 的精确控制点，预热、缓存效应、TLB miss 等都无法被建模
• 若需测量某段子逻辑（比如排除 I/O），应拆分为独立 benchmark 函数，用 state.PauseTiming() 包裹非目标代码，而非引入外部时钟
• 验证是否生效：运行后检查输出中的 iterations 字段——正常情况应远大于 1（如 10000+），若恒为 1，说明计时逻辑已被破坏

为什么 BENCHMARK_TEMPLATE 容易引发实例化爆炸

对模板函数写 BENCHMARK_TEMPLATE(my_func, int) 看似简洁，但每个特化都会生成独立符号和计时逻辑。当类型参数多于 1 个、或存在 std::vector 这类嵌套模板时，编译时间和二进制体积会指数增长，且不同特化间无法共享预热状态。

立即学习“C++免费学习笔记（深入）”；

• 优先用 auto + constexpr if 在单个 benchmark 函数内分路径，而非展开多个特化
• 若必须测多类型，用宏生成有限组合（如 int/double/std::string），避免泛型参数如 typename T 直接暴露给 BENCHMARK_TEMPLATE
• 检查编译日志中是否有大量 instantiate 提示——这是模板膨胀的明确信号