std::chrono::high_resolution_clock 不保证高精度，仅表示系统可用的最高分辨率时钟；实际精度取决于平台：windows 通常为纳秒级（queryperformancecounter），linux 依赖 clock_gettime(clock_monotonic)，macos 则仅为毫秒级（需改用 steady_clock）。
chrono::high_resolution_clock 真的“高精度”吗？
它不保证高精度，只承诺是当前系统下“可用的最高分辨率时钟”。Windows 上通常是 QueryPerformanceCounter（纳秒级），Linux 上可能是 clock_gettime(CLOCK_MONOTONIC)（通常纳秒，但实际取决于硬件和内核）。别看到“high_resolution”就默认能测 10ns 级别操作——真去测单条加法，你看到的多半是噪声。
- 用
std::chrono::high_resolution_clock::period::num和std::chrono::high_resolution_clock::period::den查实际周期（比如1/1000000000表示理论纳秒级） - 在循环中重复测量 1000+ 次再取最小值或中位数，才能压低调度、缓存预热等干扰
- 避免在测量段里调用
std::cout、内存分配、系统调用——这些开销远超待测逻辑本身
怎么写一个靠谱的计时代码片段？
别直接用 time_since_epoch() 转成秒再减，浮点误差和类型截断会悄悄吃掉精度。正确做法是全程用 duration 类型运算，最后才转成需要的单位。
- 起点：
auto start = std::chrono::high_resolution_clock::now(); - 终点：
auto end = std::chrono::high_resolution_clock::now(); - 差值：
auto dur = end - start;（类型是std::chrono::nanoseconds或类似） - 转毫秒整数：
std::chrono::duration_cast<:chrono::microseconds>(dur).count()</:chrono::microseconds> - 不要写
double(dur.count()) * dur.period::num / dur.period::den—— 多余且易错
为什么两次调用 now() 的间隔有时比预期大很多？
这不是 chrono 的 bug，而是你没隔离环境。最常见三个干扰源：编译器优化、CPU 频率动态调整、线程被抢占。
- 加
volatile或asm volatile("" ::: "memory")防止编译器把待测代码整个优化掉（尤其空循环或纯计算） - 用
taskset -c 0 ./a.out（Linux）或 Windows 的“处理器关联性”把进程绑到单核，减少跨核迁移和频率跳变 - 在测量前调用一次
std::this_thread::sleep_for(1ms)，让线程先被调度过，减少首次调度延迟毛刺 - 如果测的是函数调用开销，确保该函数不被内联——加
[[gnu::noinline]]或__declspec(noinline)
chrono 在不同平台上的行为差异
Windows 和 Linux 下 high_resolution_clock 底层实现不同，导致同一段代码在两台机器上测出的绝对数值可能差 2–3 倍，但相对趋势一致。更麻烦的是 macOS：high_resolution_clock 实际是 steady_clock 的别名，分辨率只有 15.625ms（CLOCK_UPTIME_RAW 的硬限制）。
立即学习“C++免费学习笔记（深入）”；
- macOS 上必须改用
std::chrono::steady_clock（虽名字不带 high，但实际更准） - 跨平台项目建议封装一层：用
#ifdef __APPLE__切换时钟类型 - Clang 15+ 开始支持
std::chrono::utc_clock，但和性能测量无关，别误用 - 注意 C++ 标准只要求
steady_clock单调，不保证高分辨率；而system_clock可能被 NTP 调整，绝对不能用于耗时测量
事情说清了就结束。真正难的不是调用 now()，是让两次 now() 之间只发生你想看的那一小段代码。
