std::chrono::steady_clock 是唯一可靠检测系统时钟跳变的基准，因其由硬件单调计时器驱动、不受NTP或手动调整影响；通过对比其与system_clock两次采样的时间差，可识别回拨、快进等跳变，阈值通常设为±100ms以排除抖动。
为什么 std::chrono::steady_clock 是唯一可靠选择
系统时钟（std::chrono::system_clock）可能因 NTP 同步、手动调整或夏令时切换发生跳变，直接读取它无法判断跳变本身。而 std::chrono::steady_clock 由硬件单调计时器驱动，不受系统时间修改影响，是检测跳变的基准。
关键逻辑是：用 steady_clock 做“裁判”，持续观测 system_clock 的变化是否与其流逝不匹配。
-
steady_clock的time_point永远不会倒退，两次差值即真实经过的物理时间 -
system_clock两次读取的差值可能为负（回拨）、远大于实际流逝（快进），或明显偏离steady_clock差值（例如相差 >100ms 就大概率是跳变） - 不要用
gettimeofday()或clock_gettime(CLOCK_REALTIME)替代 —— 它们和system_clock同源，本质一样
如何用两次采样发现跳变
最简可行方案是记录上一次 system_clock::now() 和对应 steady_clock::now()，本次再各取一次，比较两者的增量关系。
auto now_sys = std::chrono::system_clock::now();
auto now_steady = std::chrono::steady_clock::now();
<p>auto sys_delta = std::chrono::duration_cast<std::chrono::milliseconds>(now_sys - last_sys);
auto steady_delta = std::chrono::duration_cast<std::chrono::milliseconds>(now_steady - last_steady);</p><p>if (sys_delta.count() < -100 || sys_delta.count() > steady_delta.count() + 100 ||
sys_delta.count() < steady_delta.count() - 100) {
// 检测到跳变：回拨超 100ms，或快进/滞后超过 steady 流逝量 ±100ms
}- 阈值 100ms 是经验值：排除调度延迟、函数调用开销等微小抖动
- 必须同时检查负值（回拨）和过大正值（快进），不能只判
sys_delta - 采样间隔不宜过短（如 steady_delta 太小，相对误差放大；也不宜过长（如 >1s），错过快速连续跳变
避免被 std::chrono::high_resolution_clock 误导
在多数平台（Linux/macOS），std::chrono::high_resolution_clock 是 steady_clock 的别名；但在 Windows，它可能映射为 system_clock（取决于实现和编译器）。因此它不可靠，不能用于做“裁判”。
立即学习“C++免费学习笔记（深入）”；
- 永远显式使用
std::chrono::steady_clock，而不是依赖high_resolution_clock - 可通过
std::chrono::steady_clock::is_steady断言确认（该值必为true） - MSVC、Clang、GCC 在主流系统上对
steady_clock的实现一致且稳定，无需跨平台条件编译
生产环境需注意的隐蔽问题
检测本身不能修复跳变，但误报或漏报会引发严重后果——比如日志时间错乱、定时任务批量触发、或分布式锁超时异常。
- 单次检测结果不足以决策：建议连续 2–3 次采样均触发才上报，避免瞬时调度延迟误判
- 不要在信号处理函数中调用
system_clock::now()：某些实现（尤其旧 glibc）非异步信号安全 - 如果程序长期运行，
system_clock::time_point可能溢出（虽然要几百年），但steady_clock更早溢出（部分实现仅支持 ~36min），务必用duration_cast转成整数毫秒/微秒再算差值，而非直接减time_point
真正难的不是写检测逻辑，而是定义“可接受的跳变范围”——NTP 默认允许 ±128ms 逐步调整，这不算跳变；但用户执行 date -s 就算。边界值得结合你的业务容忍度定。
