std::chrono::high_resolution_clock 是最常用但不总是最准的选择

多数场景下用 std::chrono::high_resolution_clock 没问题，但它在不同平台行为不一致：Windows 上通常映射到 QueryPerformanceCounter，Linux 上可能是 clock_gettime(CLOCK_MONOTONIC)，但 C++ 标准只要求它“尽可能高精度”，不保证单调性或跨平台一致性。若需严格单调、抗系统时间调整，应改用 std::chrono::steady_clock。

• 测量代码段执行时间，优先选 std::chrono::steady_clock —— 它不随系统时间跳变而偏移
• high_resolution_clock 在某些旧编译器（如 GCC 4.8）可能退化为 system_clock，导致毫秒级误差
• 不要用 system_clock 测执行时间——它反映挂钟时间，可能被 NTP 调整、夏令时等干扰

正确获取两次时间点并计算差值的写法

核心是避免隐式类型转换丢失精度，且必须用 duration_cast 显式转换单位。直接对 time_point 做减法得到的是 duration，但它的底层计数器单位因实现而异（纳秒/微秒/拍秒），不能直接当浮点数用。

auto start = std::chrono::steady_clock::now();
// ... your code ...
auto end = std::chrono::steady_clock::now();
auto elapsed = std::chrono::duration_cast(end - start);
std::cout << "Time: " << elapsed.count() << " ns\n";

• 用 duration_cast 而非 C 风格强转：(double)(end - start).count() 会截断，且单位不明
• 若要毫秒浮点值，写成 std::chrono::duration(end - start).count()
• 避免把 now() 结果存成 auto 后跨作用域使用——某些 libstdc++ 实现中，time_point 的模板参数过深可能导致 ODR 违规

重复测量时要注意 warmup 和编译器优化干扰

单次测量容易受 CPU 频率突变、缓存未命中、指令重排影响。实际性能分析必须做多次采样，并剔除异常值。同时，编译器可能把“无副作用”的待测代码整个优化掉。

• 用 volatile 或 asm volatile("" ::: "memory") 防止关键计算被优化（尤其纯计算型代码段）
• 首次运行前加一次 warmup：调用待测函数一次，让指令/数据进入 L1 缓存和分支预测器
• 至少测 5–10 次，取中位数而非平均值——避免被某次缺页或中断拉高耗时
• 用 std::chrono::nanoseconds::min() 判断是否真有耗时（某些极快操作可能返回 0）

Windows 下 QueryPerformanceCounter 的替代方案更可控

如果你在 Windows 上需要确定性最高的结果，且已知目标环境支持，可绕过 std::chrono 直接调用 WinAPI：QueryPerformanceFrequency + QueryPerformanceCounter。它比标准库封装少一层抽象，也规避了某些 MSVC 版本中 steady_clock::now() 的锁竞争开销。

• 仅限 Windows；Linux 应用请坚持用 steady_clock + clock_gettime(CLOCK_MONOTONIC)
• 注意 QueryPerformanceCounter 在某些虚拟机或老 CPU 上可能不准（TSC 不稳定），需检查 QueryPerformanceFrequency 返回值是否 > 0
• 标准库的 steady_clock 在现代 MSVC（19.20+）和 Clang/LLVM 中已基本等价于该 API，除非你正在调试 nanosecond 级别抖动，否则不必手动替换

精度不是靠选对时钟就万事大吉的——CPU 频率缩放、上下文切换、TLB miss、甚至 std::chrono::now() 自身调用开销（通常几十纳秒）都会混入测量结果。真正可靠的性能对比，永远依赖统计方法和可控环境。