必须用 std::chrono::steady_clock 而非 high_resolution_clock 进行性能测试，因后者在 Windows 上可能退化为不稳定的 system_clock，导致时间跳变或负值；steady_clock 明确定义为单调递增，基于硬件计数器，满足性能测量需求。
直接结论：用 std::chrono::steady_clock，别碰 std::chrono::high_resolution_clock 做性能测试——它在 Windows 上可能退化成不稳定的 system_clock，测出的时间跳变或负值不是你代码的问题，是时钟选错了。
为什么必须用 steady_clock 而不是 high_resolution_clock
high_resolution_clock 是个“别名”，C++ 标准没规定它必须高精度或单调。实际中：
- Linux + GCC：常映射为
steady_clock，表现尚可 - Windows + MSVC：
high_resolution_clock::now()可能调用QueryPerformanceCounter，但若系统启用了某些电源管理策略，或 NTP 同步触发时，仍可能出现微小跳变；更糟的是，某些旧版 CRT 实现会 fallback 到system_clock，导致时间倒流 -
steady_clock则明确定义为“单调递增”，不响应系统时间调整，所有主流平台都基于硬件计数器（如 TSC），满足性能测量的语义需求
验证方式很简单：std::cout 必为 <code>1；而 high_resolution_clock::is_steady 在部分 Windows 环境下可能返回 0。
duration_cast 怎么用才不丢精度、不截断
直接调用 .count() 拿原始 tick 数是危险的——它没单位，且不同 clock 的 period 不同（比如 steady_clock 可能是纳秒级，但 system_clock 是微秒级）。正确做法是显式转换：
立即学习“C++免费学习笔记（深入）”；
- 要整数微秒：用
std::chrono::duration_cast<:chrono::microseconds>(end - start).count()</:chrono::microseconds> - 要保留全部纳秒精度（比如测极短函数）：用
std::chrono::duration_cast<:chrono::nanoseconds>(end - start).count()</:chrono::nanoseconds> - 要浮点毫秒（便于打印或后续计算）：用
std::chrono::duration<double std::milli>(end - start).count()</double>，注意 double 对小于 ~1ns 的间隔开始丢失精度 - 避免反复 cast：先存
auto dur = end - start;，再按需转换，减少模板实例化开销
单次测量不准？5 次取最小值比平均值更靠谱
一次测量受调度延迟、缓存未预热、TLB miss 等干扰太大，尤其测小函数时容易得到 0 或异常大值。真实项目里应：
- 循环运行待测函数 5–10 次，每次独立计时
- 取所有结果中的 最小值 —— 它最接近“无干扰下的最佳执行路径”，排除了上下文切换、缺页等噪声
- 不要用平均值：一个偶然的 2ms 延迟会让均值失真；中位数稍好，但最小值仍是工业界通用基准（如 Google Benchmark 默认策略）
- 每次测量前加
_mm_pause()或简单空循环，让 CPU 进入稳定状态（非必需，但对高频小函数有帮助）
编译器优化把待测代码删了？3 种防优化写法
加 -O2 编译后，如果函数返回值没被用到，或者循环变量没副作用，编译器可能直接优化掉整个块，测出来永远是 0。防优化方法：
- 写入
volatile变量：volatile int sink = 0; sink += expensive_computation(); - C++20 起推荐用
std::atomic_signal_fence(std::memory_order::acq_rel);阻止重排（比 volatile 更轻量） - 更通用的做法：把结果传给一个外部可见的函数，比如
doNotOptimizeAway(result);（自行定义，函数体为空但声明为extern "C"或加[[gnu::used]]） - 千万别只靠
volatile修饰输入参数——它不保证对计算过程的约束，仅对读写内存有效
真正难测的从来不是怎么写计时代码，而是怎么让被测代码“老老实实跑完还不被优化”。clock 选对只是第一步，后面每一步都得盯着编译器和运行时环境。
