应使用 std::chrono::steady_clock::now() 测量真实耗时，因其单调稳定、不受系统时间调整和休眠影响；避免用 system_clock（可能回拨）或 high_resolution_clock（C++20 已弃用且性能不稳定）；注意编译优化、环境干扰、单位转换及跨平台兼容性。
chrono 怎么测一段代码的真实耗时
别用 clock()，它只看 CPU 时间，多线程或系统调度会让结果失真；std::chrono 里的 steady_clock 才是干这个的——它不随系统时间调整跳变，也不受休眠影响，是唯一靠谱的“墙钟”计时器。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::chrono::steady_clock::now()获取起点和终点，别用system_clock（它可能回拨） - 差值转成纳秒/毫秒时，用
duration_cast显式转换，避免隐式截断：比如auto ns = duration_cast<nanoseconds>(end - start).count()</nanoseconds> - 单次测量意义不大，尤其对短函数——CPU 预热、缓存未命中、指令重排都会干扰。至少循环几百次取平均，或用 Google Benchmark 这类工具
为什么 auto t = high_resolution_clock::now() 有时反而更慢
high_resolution_clock 在不同平台底层实现不同：Linux 上常映射到 clock_gettime(CLOCK_MONOTONIC)，Windows 上可能是 QueryPerformanceCounter，但某些旧硬件或虚拟机里，它的读取开销比 steady_clock 高 2–3 倍。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 除非你明确需要 sub-microsecond 精度（且已验证硬件支持），否则默认用
steady_clock——它在所有标准实现中都保证单调+稳定 - 不要写
using namespace std::chrono;后直接写now()，容易和自定义类型冲突；显式写steady_clock::now()更安全 - 注意：C++20 起
high_resolution_clock已被标记为 deprecated，未来可能移除
chrono 计时结果不准？检查这三个地方
常见错误不是库用错了，而是环境或写法埋了坑。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 编译没关优化：
-O2或更高时，空循环、无副作用计算可能被整个优化掉。加volatile或把结果写入全局变量强制保留 - 没屏蔽干扰：运行时后台进程、磁盘 I/O、温度降频都会拉高耗时。同一台机器上多次运行，若方差 >5%，就得怀疑环境干扰
- 单位搞反：
duration_cast<milliseconds>(d).count()</milliseconds>返回的是整数毫秒，但d.count()直接调用会返回纳秒级原始 tick 数——容易误以为“1e9 就是 1 秒”，其实要看period::num / period::den
跨平台 chrono 代码怎么写才不踩兼容性雷
Windows MSVC 和 Linux GCC 对 steady_clock 的起始点（epoch）不做保证，但差值运算永远可靠；真正要小心的是输出格式和精度声明。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 别依赖
steady_clock::time_point::max()的具体值，它在 Clang 和 MSVC 下可能差几个数量级 - 打印时间戳时，用
time_since_epoch().count()+ 注明单位，而不是试图转成time_t（system_clock才能转） - 如果需与 C API 交互（如
pthread_cond_timedwait），必须用system_clock并转成timespec，steady_clock不提供这种转换接口
最易被忽略的一点：steady_clock::now() 不是零开销操作——现代 CPU 上约 20–50 纳秒，频繁调用（比如每轮循环都测）本身就会污染数据。真要压测微秒级函数，得把计时点提到外层，而不是塞进 tight loop 里。
