linux下用clock_monotonic检测系统时间跳变最可靠：启动时记录mono_start和real_start，定期比对real_elapsed与mono_elapsed差值，超2秒即判定人为修改；windows用queryperformancecounter与getsystemtimeasfiletime双源校验；跨平台应使用std::chrono::steady_clock而非system_clock。
Linux 下用 clock_gettime(CLOCK_MONOTONIC) 比对系统时间跳变
系统时间被手动修改时，time() 或 gettimeofday() 返回值可能突增或突减，但它们本身无法区分这是正常流逝还是人为篡改。真正可靠的依据是单调时钟：CLOCK_MONOTONIC 不受系统时间调整影响，只随物理时间稳定递增。
实操建议：
- 启动时调用一次
clock_gettime(CLOCK_MONOTONIC, &mono_start)和time(&real_start) - 定期（如每秒）再次获取两组值，计算差值：
real_elapsed = time_now - real_start，mono_elapsed = (current_mono - mono_start).tv_sec - 若
abs(real_elapsed - mono_elapsed) > 2（留 2 秒容错），大概率发生了手动修改 - 注意：
CLOCK_MONOTONIC在系统 suspend 期间暂停计数，若需覆盖休眠场景，改用CLOCK_MONOTONIC_RAW（Linux 2.6.28+，不补偿 TSC 漂移，但不停止）
Windows 上用 QueryPerformanceCounter + GetSystemTimeAsFileTime 做双源校验
Windows 没有直接等价于 CLOCK_MONOTONIC 的 API，但 QueryPerformanceCounter 提供高精度、不受系统时间调整影响的硬件计数器；GetSystemTimeAsFileTime 返回的是可被用户修改的系统时间（FILETIME 格式）。
实操建议：
- 初始化时调用
QueryPerformanceCounter(&perf_start)和GetSystemTimeAsFileTime(&ft_start) - 后续采样时，用
QueryPerformanceFrequency换算出性能计数器对应的真实秒数增量 - 将该增量与
ft_now - ft_start（转为毫秒）对比，偏差超过 1000ms 即触发告警 - 避免用
timeGetTime()—— 它基于系统 tick，精度低且部分版本受系统时间重设影响
跨平台检测要避开 std::chrono::system_clock 的陷阱
std::chrono::system_clock::now() 底层通常映射到 gettimeofday() 或 GetSystemTimeAsFileTime，它反映的是当前系统时间，不是运行时长。直接用它两次相减无法识别跳变——因为跳变前后它都“看起来合理”。
正确做法：
- 必须搭配一个不随系统时间变化的时钟源，比如
std::chrono::steady_clock（C++11 起要求实现为单调时钟） - 记录
steady_clock::now()和system_clock::now()的初始差值offset - 后续每次检查：若
(steady_clock::now() - steady_start) + offset与当前system_clock::now()差距显著（例如 >2s），说明 system_clock 被动过 - 注意：某些嵌入式 STL 实现中
steady_clock可能退化为system_clock，需编译期断言steady_clock::is_steady为 true
检测到时间篡改后，adjtimex() 和 SetSystemTimeAdjustment 不能用来“修复”
有人想通过调用 adjtimex()（Linux）或 SetSystemTimeAdjustment（Windows）自动补偿时间偏移，这在绝大多数场景下是危险的：
- 普通进程默认无权调用这些接口（需 CAP_SYS_TIME / SeSystemtimePrivilege），强行调用会返回
EPERM或拒绝访问 - 即使有权限，主动调整系统时钟会影响其他依赖时间的服务（如 TLS 证书校验、定时任务调度、日志时间戳一致性）
- 更稳妥的做法是记录事件、上报告警、或切换内部逻辑到仅依赖
steady_clock的模式（比如超时控制、状态轮询） - 若必须同步时间，应交由 NTP 服务（
chronyd/ntpd/ Windows Time Service）处理，而非应用层干预
真正难的不是发现跳变，而是判断这次跳变是否属于运维预期行为（比如集群统一校时）。所以生产环境建议把检测结果和上下文日志（如是否刚执行过 ntpdate、是否有 root 用户登录记录）一起留存。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
