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提示——这是模板膨胀的明确信号
Benchmark::ClobberMemory() 漏掉，或一个 --benchmark_min_time 设太小，测出来的数字就只是运行时偶然现象。 
