std::chrono::high_resolution_clock 不保证纳秒精度，其实际分辨率取决于系统：Linux 多为 1–15 纳秒，Windows 受硬件影响抖动可达微秒级；应优先使用 steady_clock，通过 period 计算真实周期，并用 volatile 或内存屏障防优化、取多次测量最小值以获可靠执行时间。
std::chrono::high_resolution_clock 真的能到纳秒吗
不能直接依赖 std::chrono::high_resolution_clock::now() 返回纳秒值——它返回的是一个时间点（time_point），底层精度由系统决定，C++ 标准只保证“尽可能高”，不保证纳秒。Linux 上通常基于 CLOCK_MONOTONIC，实际分辨率多为 1–15 纳秒；Windows 上用 QueryPerformanceCounter，理论可达 ~100 纳秒，但受硬件和电源管理影响，抖动可能达微秒级。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 别硬转成
nanoseconds再输出——先用duration_cast转成你真正需要的单位（比如nanoseconds或microseconds），再调.count() - 用
steady_clock替代high_resolution_clock更稳妥：它不跳变、单调递增，且多数平台下和high_resolution_clock实际是同一个类型 - 检查实际分辨率：
std::chrono::high_resolution_clock::period::num / std::chrono::high_resolution_clock::period::den可算出周期（如1/1000000000表示纳秒级）
怎么测一段代码的真实执行时间（避免编译器优化干扰）
常见错误是写完 auto start = steady_clock::now(); 就直接跑目标代码，结果编译器把整个块优化掉，或者因 CPU 频率变化、缓存未热导致结果波动极大。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
volatile或内存屏障防止优化：对关键变量加volatile，或在计时前后插入asm volatile("" ::: "memory") - 重复多次取最小值而非平均值：单次测量易受中断、调度干扰；运行 100+ 次，取最小耗时更接近“纯计算开销”
- 确保被测代码有副作用（比如写入
volatile int sink），否则可能被整个删掉 - 示例片段：
volatile int sink = 0; auto start = std::chrono::steady_clock::now(); for (int i = 0; i < 100; ++i) { sink += some_computation(i); } auto end = std::chrono::steady_clock::now(); auto ns = std::chrono::duration_cast<std::chrono::nanoseconds>(end - start).count();
为什么两次 duration_cast<nanoseconds> 结果差几十纳秒
这不是误差，是正常现象。每次 now() 调用本身就有开销（几纳秒到几十纳秒），而且现代 CPU 的 TSC（时间戳计数器）并非完全线性——频率缩放、跨核迁移、SMT 超线程都会引入偏差。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 不要单独测量一次
now()调用耗时：它没有意义，且结果不可比 - 避免在循环内高频调用
now()：每调一次都有固定开销，叠加后失真严重 - 若需亚微秒级分析，考虑用 perf_event 或 Intel PT 等硬件级工具，
std::chrono不是为此设计的 - 跨线程计时时，注意
steady_clock在所有线程中是统一单调的，但不同核的 TSC 同步延迟可能导致 10–100ns 级偏差
Windows 下 QueryPerformanceCounter 和 std::chrono 的兼容性问题
MSVC 的 steady_clock 底层就是 QueryPerformanceCounter，但存在两个隐藏坑：一是某些旧 BIOS 或虚拟机里 QPC 不可靠，二是 Windows 10 1809+ 默认启用“Enhanced Timer Resolution”，可能让 QPC 返回值与系统时钟漂移。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 生产环境务必测试：在目标机器上跑一段已知耗时的空循环，对比
std::chrono和GetTickCount64的长期漂移 - 避免混用 WinAPI 和
std::chrono时间点：比如拿QPC值直接减steady_clock::now()，类型和 epoch 不同，结果无意义 - 如果必须高一致性的长时间测量（>1 小时），定期用
system_clock校准steady_clock偏差（虽然违背了 steady 的本意，但现实有时得妥协）
纳秒级计时真正的复杂点不在 API 调用，而在理解“你到底想测什么”——是函数本身？上下文切换？缓存预热？还是 CPU 频率突变的影响。这些没法靠换一个 duration_cast 解决。
