优先选 high_resolution_clock 而不是 steady_clock，因其在现代平台实际支持纳秒级精度，而 steady_clock 在旧编译器中分辨率仅毫秒级；但需用 duration_cast 显式转换单位，取多次测量最小值，并避免系统调用干扰。
直接用 std::chrono::high_resolution_clock，别碰 clock() 或 std::chrono::system_clock——前者测的是 CPU 时间，后者可能跳变；后者在 NTP 同步或夏令时调整时会回退，完全不适合计时。
为什么优先选 high_resolution_clock 而不是 steady_clock
std::chrono::steady_clock 确实单调、不跳变，适合做超时判断，但部分旧编译器（如 GCC 4.8、MSVC 2013）实现中其分辨率只有毫秒级；而 std::chrono::high_resolution_clock 是标准中唯一明确“尽可能高精度”的时钟，在现代 Linux/macOS/Windows 上基本都映射到 CLOCK_MONOTONIC 或 QueryPerformanceCounter，实际支持纳秒级差值运算。
- 查证方式：打印
decltype(now())::period::num和decltype(now())::period::den，比如1/1000000000表示纳秒级 - 不要依赖它“返回纳秒值”——它返回的是 time_point，单位由底层实现决定；真正可靠的是差值 +
duration_cast - 若你只关心相对耗时（比如比对两个算法），
steady_clock更稳；但要测微秒/纳秒级真实 wall-clock 耗时，high_resolution_clock是更优起点
duration_cast 是必须的，auto diff = end - start 不够安全
写 auto diff = end - start; 看似简洁，但 diff.count() 返回的是“滴答数”，不是微秒也不是纳秒——它取决于当前 duration 的 period。比如某平台下 high_resolution_clock::duration 实际是 microseconds，那 diff.count() 就是微秒数；换台机器变成 nanoseconds，同样代码就溢出或截断。
- 正确做法：显式用
std::chrono::duration_cast<:chrono::microseconds>(end - start)</:chrono::microseconds> - 然后调
.count()，返回long long，不会被int截断 - 避免写
(end - start).count() * 1000这类手动换算——单位不明确，跨平台易错
单次测量不准，循环取最小值才接近真实开销
一次 now() 调用本身就有几十纳秒开销，加上线程调度、缓存预热、TLB miss、CPU 频率升降，单次结果波动极大。比如测一个空循环，可能得到 0、83、217、156 纳秒等完全不一致的值。
立即学习“C++免费学习笔记（深入）”；
- 实操建议：外层套 100~1000 次循环，记录每次
duration_cast<:chrono::nanoseconds>(end - start).count()</:chrono::nanoseconds>，取最小值（排除调度干扰）或中位数（抗异常值） - 计时区间内禁止日志输出、内存分配、系统调用——这些会污染测量结果
- 加
volatile变量防优化，比如volatile int sink = 0; sink += compute();，确保编译器不删掉你要测的逻辑
最常被忽略的一点：high_resolution_clock 在 Windows 7 + VC2013 这类老旧环境里，period::den 可能是 10000000（即 100 纳秒一滴答），此时 duration_cast<:chrono::nanoseconds></:chrono::nanoseconds> 会向上取整失真；真有兼容性要求，得 fallback 到 QueryPerformanceCounter 手动算，而不是无脑信模板。
