std::chrono::steady_clock与system_clock语义不同：前者单调递增、抗校准，适合测时长；后者映射系统实时时钟、受ntp等影响，适合绝对时间。混用会导致负值或跳变，非bug而是设计使然。
为什么 std::chrono::steady_clock 和 std::chrono::system_clock 时间戳看起来“不同步”
这不是时钟本身出错，而是两种时钟语义完全不同：steady_clock 保证单调递增、不受系统时间调整影响，适合测间隔；system_clock 对应系统实时时钟（可能被 NTP、手动修改、闰秒等扰动）。多线程中若混用二者并直接比较数值，必然出现“跳变”或“倒流”——这不是 bug，是设计使然。
常见错误现象包括：
- 主线程用
system_clock::now()打日志时间，工作线程用steady_clock::now()计算耗时，结果相减得到负数或极大值 - 多个线程各自记录
system_clock::now()，发现时间差远超预期（比如相差几秒），实际是某线程启动前系统时间刚被 NTP 校正过
怎么统一多线程时间基准：选对时钟 + 显式转换
如果目标是“所有线程看到同一套可比的时间点”，必须固定使用一种时钟，并避免隐式转换。优先选 system_clock（需注意校准风险）或 steady_clock（仅用于相对测量）。
实操建议：
- 全项目约定一个基准时钟，例如定义
using app_clock = std::chrono::system_clock;，所有打点、日志、超时判断都用它 - 若必须用
steady_clock做耗时统计，不要把它和system_clock的时间戳做算术运算；如需关联，用system_clock::now()在关键路径起点/终点各记一次，中间用steady_clock插值 - 跨线程传递时间戳时，传
time_point值本身，别传毫秒整数——避免隐式截断或时区误解释
调试时如何快速定位时间源混乱点
在日志或调试器里看到异常时间差，先确认每个时间戳的类型，而不是只看数值。C++ 中 decltype(t).name()（配合 abi::__cxa_demangle）能帮你识别，但更简单的是加编译期断言：
static_assert(std::is_same_v<decltype std::chrono::system_clock::time_point>, "time point must be system_clock");</decltype>
另外，加运行时检查：
- 在线程入口处打一行日志：
LOG(INFO) - 对比两列数值的增长趋势：前者可能跳变，后者一定单调；若后者也倒退，说明系统过载或
steady_clock实现异常（极少见，多见于虚拟机或老旧内核）
Linux 下 clock_gettime(CLOCK_MONOTONIC) 和 CLOCK_REALTIME 的映射关系
C++ 标准库的 steady_clock 通常底层调用 CLOCK_MONOTONIC，system_clock 对应 CLOCK_REALTIME。它们的偏移不是常量——内核会动态维护两者关系，尤其在 NTP 调整期间。
这意味着：
- 不能假设
system_clock::now() - steady_clock::now()是固定值；这个差值本身随时间缓慢漂移 - gdb 调试时若看到
steady_clock::now()返回值突然变小，大概率是线程被调度到不同 CPU 核，而该核的 TSC 不稳定（常见于某些 Xen/KVM 环境），此时应改用CLOCK_MONOTONIC_RAW（需自定义时钟类） - 生产环境若需高精度同步，避免依赖单次时间戳差值，改用周期性采样 + 滑动窗口拟合偏移
真正难处理的不是“不同步”，而是混用却不自知——类型擦除、模板推导、日志宏封装都可能悄悄把 steady_clock::time_point 当成 system_clock::time_point 用。盯紧变量声明和日志输出类型，比加锁还重要。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
