应优先使用 std::chrono::steady_clock 测量耗时，因其单调递增、不受系统时间调整影响；high_resolution_clock 行为因平台而异，不可靠；计时需两次 now() 并用 duration_cast 转换。
chrono::high_resolution_clock 是最常用但未必最稳的选择
在多数场景下，std::chrono::high_resolution_clock 看起来是“高精度”的默认答案，但它在不同平台行为不一致：Windows 上通常映射为 steady_clock，而 Linux 上可能退化为 system_clock（受系统时间调整影响）。如果你测的是算法执行时间，必须避免被 NTP 校时或手动改系统时间干扰。
实操建议：
- 优先用
std::chrono::steady_clock——它保证单调递增，不受系统时间变更影响，专为测量耗时设计 - 若需和系统时间对齐（比如打日志时间戳），再单独调用
system_clock::now() - 不要依赖
high_resolution_clock::is_steady的返回值做运行时分支——C++ 标准只要求它“尽力”，不保证跨平台一致
计时代码模板必须包含两次 now() + duration_cast
常见错误是只调一次 now()，或漏掉 duration_cast 直接输出 time_point。实际上 time_point 本身不能直接相减成“毫秒数”，必须显式转为目标时长类型。
正确写法示例：
立即学习“C++免费学习笔记（深入）”；
auto start = std::chrono::steady_clock::now(); // ... your code here ... auto end = std::chrono::steady_clock::now(); auto elapsed = std::chrono::duration_cast<std::chrono::microseconds>(end - start); std::cout << "cost: " << elapsed.count() << " μs\n";
注意点：
-
duration_cast截断而非四舍五入，比如 1234.9μs 转milliseconds得到 1ms - 想保留小数？用
std::chrono::duration<double std::micro></double>或除以1000.0手动换算 - 避免用
clock()或gettimeofday()——它们精度低、可移植性差、且不属 C++ 标准时序接口
循环测试要防编译器优化把代码“优化没了”
写个 for 循环测函数耗时，结果打印出来总是 0μs？大概率是编译器发现你没用返回值、也没副作用，直接把整个循环干掉了。
让计时有意义的几个关键操作：
- 把待测函数的**返回值赋给 volatile 变量**，例如：
volatile auto result = my_func(); - 或者用
asm volatile("" ::: "memory");插入内存屏障（GCC/Clang） - Release 模式下测试前，先确认
-O2或-O3没把目标逻辑内联并折叠——可临时加[[gnu::optimize("O0")]]属性（GCC）或查看汇编输出 - 单次耗时太短（如纳秒级）？重复执行 N 次再除以 N，但注意别引入循环开销偏差（N ≥ 10000 更稳妥）
Windows 下 QueryPerformanceCounter 精度更高但没必要手动封装
确实，QueryPerformanceCounter 在 Windows 上能提供接近 CPU 周期级的稳定性，比 steady_clock 理论上更准。但现代 MSVC 和 Clang 对 steady_clock 的实现已直接基于 QPC，无需自己调 Win32 API。
除非你遇到这些情况，否则别碰原生 API：
- 需要微秒以下分辨率（如 100ns 量级）且确认硬件支持
- 做实时系统或硬实时性能分析，要求误差绝对低于 1μs
- 正在写跨平台底层库，且明确知道各平台
steady_clock实现缺陷（极少见）
自己封装 QPC 容易踩坑：频率查询失败、除零、整数溢出、多核 TSC 不同步等问题，得不偿失。
