最可靠方法是用 std::chrono::high_resolution_clock 配合 duration_cast 测微秒耗时，因其跨平台精度高且避免 system_clock 的时间调整问题，同时需避免函数调用开销、使用 release 模式并排除异常等干扰。
用 std::chrono::high_resolution_clock 测微秒级耗时最可靠
Windows 上 std::chrono::steady_clock 可能回退或跳变，Linux/macOS 上它通常基于 CLOCK_MONOTONIC，但跨平台一致性和分辨率不如 high_resolution_clock。C++ 标准不强制规定其底层实现，但主流编译器（GCC、Clang、MSVC）都让 high_resolution_clock 绑定到系统最高精度计时源（如 TSC、QueryPerformanceCounter），实测在多数环境下能稳定返回纳秒级 tick，除以 1000 即得微秒。
别用 system_clock —— 它对应系统时间，可能被 NTP 调整，测耗时不适用。
duration_cast<microseconds></microseconds> 是转换到微秒的唯一安全方式
直接对 duration 做除法（比如 count() / 1000）会丢精度：若原始单位是纳秒，count() 是整数，除法截断导致误差累积。必须用 duration_cast 让标准库做带舍入的类型转换。
示例：
auto start = std::chrono::high_resolution_clock::now(); // ... your code ... auto end = std::chrono::high_resolution_clock::now(); auto us = std::chrono::duration_cast<:chrono::microseconds>(end - start).count();</:chrono::microseconds>
注意：count() 返回的是 long long 整数，不是浮点；如果需要小数微秒（比如 12.34 µs），改用 duration_cast<duration std::micro>>(...).count()</duration>。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
避免常见陷阱：两次 now() 调用之间不能有函数调用开销干扰
如果你把耗时测量封装成宏或函数，会引入额外调用开销，尤其在循环内高频测量时，这部分开销会被计入结果。
- 不要写
MEASURE_US({ ... })这类宏，除非宏内联且无函数调用 - 不要把
now()包进辅助函数里——函数调用本身要几十纳秒 - 单次测量值意义有限；建议重复运行 100+ 次取最小值或中位数，排除调度抖动和缓存预热影响
- Release 模式下编译，Debug 模式中编译器插入的调试检查会严重污染测量结果
Windows 下 MSVC 的 high_resolution_clock::is_steady 返回 false？没关系
MSVC 实现中，high_resolution_clock 底层用 QueryPerformanceCounter，虽不满足 is_steady == true（因 Windows 文档未保证其绝对单调），但实践中极少发生倒退。只要你不跨进程/跨机器比对时间点，只算差值，就完全可用。
若静态分析工具报 warning，可显式加 static_assert(std::chrono::high_resolution_clock::is_steady || true, "..."); 压制（仅限内部工具链）。
真正要注意的是：别在测量区间内触发异常、系统调用（如 std::cout）、内存分配（new）、锁竞争——这些操作的耗时远大于时钟本身的不确定性。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
