std::chrono::high_resolution_clock 不保证纳秒级精度，其实际分辨率取决于系统API和硬件，即使 duration::period::den 为1，真实tick间隔可能达几十纳秒或微秒级。
std::chrono::high_resolution_clock 并不保证纳秒级精度
很多开发者看到 high_resolution_clock 就默认它能返回纳秒值，实际并非如此。它的底层实现依赖系统 API（Windows 上通常是 QueryPerformanceCounter，Linux 上是 clock_gettime(CLOCK_MONOTONIC)），分辨率由硬件和内核决定。即使 duration::period::den 是 1（即理论上支持纳秒），真实 tick 间隔可能是几十纳秒甚至微秒级。
验证方法很简单：
duration_cast
- 正确用法：统一单位做差值计算，例如测函数耗时
- 错误预期：认为
.time_since_epoch().count()返回的是绝对纳秒时间戳（可用于跨进程对齐） - 注意：不同 clock 类型（
system_clock、steady_clock、high_resolution_clock）的 epoch 不同，time_since_epoch()值不可直接比较
跨平台纳秒时间戳需组合 system_clock + steady_clock
若真需要高精度且可比的绝对时间（如日志打点、分布式 trace），不能只靠 high_resolution_clock。推荐做法是：用 system_clock 获取带时区的秒级基准（保证绝对时间语义），再用 steady_clock 做高精度增量，定期校准偏移。
简易校准示例（非实时同步，仅示意逻辑）：
auto sys_now = std::chrono::system_clock::now(); auto steady_now = std::chrono::steady_clock::now(); auto offset = sys_now.time_since_epoch() - steady_now.time_since_epoch();
后续每次获取“高精度绝对时间”时：
auto steady_t = std::chrono::steady_clock::now(); auto abs_ns = (steady_t.time_since_epoch() + offset).count(); // 单位：纳秒，基于 system_clock epoch
注意：offset 会随系统时间调整漂移，生产环境需用 NTP 或 PTP 同步策略更新。
避免 std::chrono::time_point 构造时的隐式截断
当你把一个 nanoseconds duration 赋给 time_point，而该 clock 的 period 更粗（如 microsecond），会发生向下取整截断：
using MyClock = std::chrono::duration<long std::micro>;
std::chrono::time_point<myclock> tp{
std::chrono::nanoseconds{1234} // → 实际存为 1μs，丢失 234ns
};</myclock></long>
这类问题在模板推导或跨 clock 转换时极易发生。安全做法是：
- 显式使用
time_point_cast并检查是否丢精度：time_point_cast(tp).time_since_epoch().count() - 优先用
auto推导类型，避免手动指定不匹配的 clock - 打印调试时，统一转成
nanoseconds再输出：tp.time_since_epoch().count()不可靠，应先 cast
最常被忽略的一点：std::chrono::high_resolution_clock::now() 返回的 time_point 类型在不同编译器/平台可能不同（GCC 常为 nanoseconds，MSVC 可能是 nanoseconds 或 picoseconds），硬编码类型会导致移植失败。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
