应使用 std::chrono::steady_clock 获取微秒级稳定时间间隔，它基于单调时钟源、不受系统时间调整影响，且精度足够；避免 system_clock、clock() 和 gettimeofday()；正确做法是两次 now() 相减后用 duration_cast 转换再调用 count()。
用 std::chrono::steady_clock 获取高精度时间点
微秒级间隔要求时钟源稳定、无跳变，且分辨率足够。推荐用 std::chrono::steady_clock，它不随系统时间调整而偏移，且在大多数现代平台（Linux/macOS/Windows）下底层基于 CLOCK_MONOTONIC 或 QueryPerformanceCounter，天然支持纳秒或微秒级精度。
注意：不要用 std::chrono::system_clock——它映射系统时间，可能因 NTP 调整导致负间隔；也不要依赖 clock() 或 gettimeofday()，它们已被 C++ 标准弃用或精度不足。
实操建议：
- 直接调用
std::chrono::steady_clock::now()两次，返回time_point - 两次结果相减得到
duration，再用count()提取数值 - 若需微秒值，显式转换为
std::chrono::microseconds，避免隐式截断
正确转换为微秒整数的三步写法
常见错误是直接对 duration 调用 count() 而不指定单位，结果取决于底层时钟周期（如纳秒），导致数值比预期大 1000 倍。
立即学习“C++免费学习笔记（深入）”；
安全写法（C++11 起通用）：
auto start = std::chrono::steady_clock::now(); // ... 业务逻辑 ... auto end = std::chrono::steady_clock::now(); <p>auto us = std::chrono::duration_cast<std::chrono::microseconds>(end - start).count();
关键点：
-
duration_cast是显式向下取整（向零截断），不是四舍五入 - 若需更高精度中间值（如纳秒），可先转
std::chrono::nanoseconds再除以 1000.0 得 double 微秒 - 避免写成
(end - start).count() / 1000—— 不同平台count()单位不同，不可移植
Windows 下 QueryPerformanceCounter 的兼容性陷阱
如果你在 Windows 上手写高性能计时器（比如绕过 STL），必须注意 QueryPerformanceCounter 返回的 tick 数不能直接当微秒用——它的频率由 QueryPerformanceFrequency 决定，可能是 10 MHz、15.625 MHz 或其他值，不是固定 1 MHz。
典型误用：
LARGE_INTEGER freq, start, end; QueryPerformanceFrequency(&freq); // freq.QuadPart 可能是 10000000 QueryPerformanceCounter(&start); // ... QueryPerformanceCounter(&end); auto us = (end.QuadPart - start.QuadPart) / 1000; // ❌ 错！没除 freq
正确做法：
- 必须用
(end.QuadPart - start.QuadPart) * 1000000 / freq.QuadPart才得微秒（整数运算防溢出） - 更稳妥：用
double计算：(end.QuadPart - start.QuadPart) * 1e6 / freq.QuadPart - 除非有极端性能要求且已验证平台时钟稳定性，否则优先用
std::chrono
跨线程或长时测量时的精度衰减问题
steady_clock 在单次测量中误差极小（通常 now() 调用间隔超过数小时，某些平台（尤其是虚拟机或老旧 BIOS）可能出现累积漂移，表现为微秒值异常偏大。
应对方式：
- 对毫秒级以上间隔，改用
std::chrono::milliseconds转换，避免microseconds::count()溢出（int64 最大约 292 年，但实际常被缩放到 int32 存储） - 若需长时间跨度高精度，应定期校准（例如每 10 分钟与
std::chrono::system_clock同步一次差值） - 不要假设两次
now()调用之间 CPU 频率恒定——DVFS、节能模式会动态降频，影响指令执行时间，但这不影响steady_clock自身读数，只影响业务逻辑耗时解释
微秒级时间差看似简单，真正难的是理解「时钟源」和「单位转换」这两层抽象——漏掉任意一层，测出来的数字就只是个整数，不是真实微秒。
