std::chrono::high_resolution_clock是最稳妥的选择，它在主流平台映射到系统最高精度时钟源，g++/clang/msvc均支持且不依赖第三方库；但需注意windows旧版可能退化为毫秒级，应运行时检查period确认精度。
用 std::chrono::high_resolution_clock 是最稳妥的选择
它在主流平台（Linux/macOS/Windows）上基本都映射到系统最高精度时钟源，g++/clang/MSVC 都支持，且不依赖第三方库。别去手动调 clock_gettime(CLOCK_MONOTONIC, ...) 或 QueryPerformanceCounter——跨平台封装成本高，还容易漏掉初始化失败分支。
常见错误是误以为 std::chrono::steady_clock 一定比 high_resolution_clock 更“稳”：其实两者在大多数实现中底层相同，但 steady_clock 保证单调性，high_resolution_clock 保证精度；性能测试需要的是后者返回的 tick 周期更小，实测通常为 1ns 级（Linux x86_64 下常为 1ns，Windows 上取决于硬件，但一般 ≤15.6ns）。
- 直接用
time_point相减即可得duration，无需手动除法或换算 - 避免用
system_clock：它可能受 NTP 调整影响，基准测试中会导致时间倒流或跳变 - 构造
time_point时不要用默认构造（如auto t = high_resolution_clock::time_point{}），应调用now()
测量单次函数耗时必须规避编译器优化和缓存干扰
只跑一次 high_resolution_clock::now() 前后取差，结果不可信——函数可能被内联、指令重排，或 CPU 还没真正执行完就返回了。尤其对微秒级以下操作，误差常达几十纳秒。
典型错误现象：duration_cast<nanoseconds>(end - start).count()</nanoseconds> 返回 0，不是因为快，而是因为没真正执行，或者被优化掉了。
立即学习“C++免费学习笔记（深入）”；
- 把待测函数体用
volatile变量或asm volatile("" ::: "memory")强制防止优化（GCC/Clang） - Windows MSVC 用
_ReadWriteBarrier()或__builtin_trap()类似效果 - 至少重复运行数百次取最小值（而非平均值），排除调度抖动和 TLB miss 干扰
- 用
std::atomic_thread_fence(std::memory_order_seq_cst)防止指令乱序影响起点/终点捕获
duration_cast 的截断行为容易导致精度丢失
毫秒级显示不等于毫秒级精度。比如你用 duration_cast<milliseconds></milliseconds> 把一个 999ns 的 duration 转成 milliseconds，结果是 0——这不是计时不准，是显式向下截断。
性能基准中若只看毫秒值，可能把 0.9ms 和 0.1ms 都显示为 0ms，完全掩盖差异。
- 真要毫秒精度显示，先转成
nanoseconds，再除以 1'000'000.0 得 double 毫秒值 - 或用
duration_cast<microseconds></microseconds>+ 小数点后一位，兼顾可读与分辨率 - 注意
auto d = end - start;后，d.count()返回的是底层 tick 数，类型取决于时钟实现，别假设一定是 nanoseconds
Windows 上 high_resolution_clock 可能退化为毫秒级
旧版 MSVC（如 VS2015）或某些 Windows 版本下，high_resolution_clock::period::den 可能是 1000，即最低分辨率为 1ms。这不是 bug，是 Windows API 层限制（如 GetTickCount64 回退路径）。
运行时可通过检查 high_resolution_clock::period::num / high_resolution_clock::period::den 判断实际精度：若大于 1μs，就得警惕。
- 编译时加
/D _HAS_AUTO_PTR_ETC=1（新标准库）有助于启用 QueryPerformanceCounter - 实测建议在目标机器上打印
decltype(high_resolution_clock::now())::period::den确认 - 若发现精度不足，可 fallback 到
std::chrono::steady_clock（它在 Win10+ 通常也是 QPC-backed）
精度不等于稳定性，高分辨率时钟本身也可能有微秒级抖动；真正影响基准结果的，往往是内存访问模式、CPU 频率缩放、以及是否绑核——这些比选哪个 clock 更关键。
