应使用 chrono::steady_clock 测量代码耗时，因其单调不倒退、不受系统时间调整影响；需统一时钟类型、避免跨时钟转换；用 duration_cast 显式转换单位；显式声明 time_point 类型；在 release 模式下测试。
chrono::steady_clock 是最稳妥的计时起点
需要精确测量代码段耗时，就别用 system_clock 或 high_resolution_clock——前者可能因系统时间调整跳变，后者在某些平台（如 macOS）只是 system_clock 的别名，不保证单调。直接用 steady_clock，它专为间隔测量设计，不会倒退、不受系统时钟修改影响。
实操建议：
- 起始和结束都用同一时钟类型，例如
auto start = std::chrono::steady_clock::now() - 避免跨时钟转换，比如把
steady_clock::time_point强转成system_clock::time_point，会触发未定义行为 - 如果要测单次执行时间，确保被测代码不被编译器优化掉（加
volatile或用asm volatile("" ::: "memory")作为内存屏障）
duration_cast 是单位换算的关键函数
计时结果是 duration 类型，不能直接输出或比较数值，必须显式转换。常见错误是写 auto diff = end - start 后直接除以 1000 当毫秒用——这实际得到的是纳秒数除以 1000 的整数，精度丢失且语义模糊。
正确做法是用 std::chrono::duration_cast：
立即学习“C++免费学习笔记（深入）”；
auto start = std::chrono::steady_clock::now(); // ... 被测代码 auto end = std::chrono::steady_clock::now(); auto diff = end - start; auto ms = std::chrono::duration_cast<std::chrono::milliseconds>(diff).count(); // 得到 long long 毫秒数 auto us = std::chrono::duration_cast<std::chrono::microseconds>(diff).count(); // 微秒数
注意：duration_cast 截断而非四舍五入；若需更高精度浮点值，改用 std::chrono::duration<double, std::milli> 构造。
避免 auto 推导 time_point 时的隐式陷阱
写 auto t = std::chrono::steady_clock::now() 看似方便，但后续若混用不同精度的时钟（比如把 steady_clock::now() 和 high_resolution_clock::now() 相减），编译器可能静默接受，运行时却因内部表示差异导致极大误差。
更隐蔽的问题是：某些旧版 libstdc++ 中，auto 推导出的 time_point 可能绑定到临时对象，引发悬垂引用（尤其在 lambda 捕获中）。稳妥做法是显式声明类型：
- 用
std::chrono::steady_clock::time_point start;明确类型 - 或至少用
const auto start = ...防止后续意外赋值 - 在循环内重复计时时，别在循环外只声明一次
time_point变量然后反复赋值——每次都要调用now()获取新快照
release 模式下计时结果才反映真实性能
debug 模式开启调试符号、禁用优化，函数内联失效、边界检查全开，测出来的耗时和 release 完全不是一回事。尤其涉及小函数、空循环、简单算术时，debug 下可能慢几倍甚至几十倍。
实操要点：
- 务必在
-O2或-O3下编译后运行计时代码 - 对极短操作（std::chrono::nanoseconds 级别捕获
- 注意 CPU 频率缩放、温度降频、其他进程抢占等外部干扰，多次运行取中位数比单次更可靠
真正容易被忽略的是：即使用了 steady_clock 和 duration_cast，如果没关优化、没跑在稳定负载下，数字再“准”也没参考价值。
