chrono::high_resolution_clock 并非总是高精度：Windows 上实为 system_clock 别名（分辨率约15–16ms），Linux 上才更接近纳秒级；测代码耗时应优先用 steady_clock，它单调、稳定、分辨率更高。
chrono::high_resolution_clock 真的高精度吗？
它不总是你想要的“最高精度”——在 Windows 上，high_resolution_clock 通常是 system_clock 的别名（基于 GetSystemTimeAsFileTime），分辨率约 15–16ms；Linux 上才更可能映射到 clock_gettime(CLOCK_MONOTONIC)。别被名字骗了。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 需要真正高精度（纳秒级）且跨平台稳定？优先用
steady_clock，它保证单调、无跳变，分辨率通常优于system_clock - 测代码耗时？必须用
steady_clock，避免系统时间调整导致负值或突变 - 记录日志时间戳？才用
system_clock，它对应真实世界时间 - Windows 下若需 sub-millisecond 级别，可考虑
QueryPerformanceCounter，但steady_clock已足够大多数场景
怎么正确测量一段代码的执行时间？
核心是避免隐式转换和单位误用，尤其别直接用 duration_cast 强转到 milliseconds 再除以 1000 得秒——会丢精度。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
auto start = std::chrono::steady_clock::now()和auto end = std::chrono::steady_clock::now()获取时间点 - 差值是
std::chrono::duration类型，直接调用.count()取原始计数值，再配合.period::num / .period::den理解单位（比如 nanoseconds 是 1/1000000000 秒） - 打印时推荐：用
std::chrono::duration<double std::nano></double>转成带小数的纳秒，或std::chrono::duration<double std::milli></double>得毫秒浮点数 - 错误示范：
auto ms = std::chrono::duration_cast<:chrono::milliseconds>(end - start).count()</:chrono::milliseconds>—— 整数截断，
auto start = std::chrono::steady_clock::now(); // ... your code ... auto end = std::chrono::steady_clock::now(); auto elapsed = end - start; std::cout << "Took: " << std::chrono::duration<double, std::nano>(elapsed).count() << " ns\n";
为什么 duration_cast 有时结果为 0？
不是计时失败，而是你 cast 到的单位太大，而实际耗时小于一个单位——比如耗时 800ns，cast 到 std::chrono::milliseconds 就得 0。
常见错误现象：
- 测空循环或极快函数，输出全是 0ms
- 用
.count()直接打印整数毫秒，却忘了原始 duration 实际是 nanoseconds - 跨线程或 CPU 频率变化未考虑（但 chrono 本身已屏蔽大部分硬件差异）
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 先用
std::chrono::nanoseconds或std::chrono::microseconds观察原始量级 - 避免对短于目标单位的 duration 做整数 cast；改用浮点 duration（如
std::chrono::duration<double std::milli></double>） - 单次测量不准？加循环多次运行，取总时间再平均（注意编译器优化可能把空循环干掉，加
volatile或用doNotOptimizeAway类辅助）
chrono 在 release 和 debug 模式下结果差很多正常吗？
非常正常——debug 模式下编译器几乎不优化，函数调用开销、边界检查、未内联都会拉长时间；release 下内联、常量传播、死代码消除会让耗时骤降，甚至归零。
使用场景提醒：
- 性能调优只看 release + 同等编译选项（如 -O2/-O3、/O2）下的结果
- debug 下测出 10ms 不代表 release 下也是 10ms，可能变成 0.02ms
- 想排除编译器优化干扰？用
std::chrono::volatile无意义；真正有效的是把被测变量标volatile，或用类似 Google Benchmark 的DoNotOptimize阻止优化 - Release 下测出 0？说明函数太快，或被整个优化掉了——加个
asm volatile("" ::: "memory")或用std::black_box（C++23）保活
精度和稳定性不在 clock 类型名字里，而在你选对 clock、用对 duration、避开整数截断、匹配构建配置——这些地方错一点，测出来的时间就和真实行为脱节了。
