std::high_resolution_clock并非跨平台稳定高精度时钟：Windows常退化为毫秒级system_clock，Linux/macOS通常为纳秒级；测量应使用duration_cast转换单位，优先选用steady_clock而非high_resolution_clock。
直接说结论：std::high_resolution_clock 在 C++11 及以后是标准库提供的“理论上精度最高”的时钟类型，但它**不是跨平台稳定可用的高精度计时器**——在 Windows 上它常退化为 std::system_clock（毫秒级），Linux/macOS 通常对应纳秒级的 CLOCK_MONOTONIC。真要可靠测微秒/纳秒级耗时，得用它，但必须配合正确用法和平台意识。
为什么 std::high_resolution_clock::now() 返回值不能直接相减？
它返回的是 std::chrono::time_point，底层是 duration 类型，但其 rep（表示值）和 period（时间单位）因平台而异。直接输出 .time_since_epoch().count() 可能是纳秒、微秒甚至毫秒，不加转换就当“纳秒数”用会出错。
- Windows MSVC：通常
period = std::ratio（100 纳秒单位） - Linux Clang/GCC：通常
period = std::ratio（1 纳秒单位） - 别硬记，用
std::chrono::duration_cast转换到目标单位
怎么安全地测量一段代码的执行时间？
核心是：用 time_point 相减得 duration，再显式转成你需要的单位（如 nanoseconds 或 microseconds），避免依赖底层 count() 的原始含义。
#include <chrono>
#include <iostream><p>int main() {
auto start = std::chrono::high_resolution_clock::now();</p><pre class='brush:php;toolbar:false;'>// 模拟待测代码
volatile int x = 0;
for (int i = 0; i < 1000; ++i) x += i;
auto end = std::chrono::high_resolution_clock::now();
auto duration = end - start;
auto ns = std::chrono::duration_cast<std::chrono::nanoseconds>(duration).count();
auto us = std::chrono::duration_cast<std::chrono::microseconds>(duration).count();
std::cout << "Time: " << ns << " ns (" << us << " μs)\n";}
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 必须用
volatile防止编译器优化掉待测代码（尤其空循环或无副作用计算） - 单次测量意义不大，建议循环多次取平均，并用
std::chrono::steady_clock做稳定性校验（见下条） - 不要用
duration.count()直接打印——它可能不是纳秒
std::high_resolution_clock 和 std::steady_clock 到底该用哪个？
这是最容易混淆的点：high_resolution_clock 是“精度高”，steady_clock 是“单调不回拨”。实际性能分析中，优先选 steady_clock。
-
steady_clock保证时间差恒正、不受系统时间调整影响，适合测间隔 -
high_resolution_clock在部分平台（如旧版 MSVC）只是system_clock的别名，精度反而不如steady_clock - C++20 起，
high_resolution_clock已被标记为“不推荐使用”，标准建议用steady_clock替代 - 如果你非要纳秒级，且确认平台支持（如 Linux + GCC），可继续用
high_resolution_clock，但务必加duration_cast
真正难的不是写对那几行 now() 和 duration_cast，而是理解：时钟类型选择、编译器优化干扰、平台实现差异、以及单次测量的统计噪声——这些比语法细节更容易让结果失真。
