c++oding="utf-8" ?>
system_clock可转time_t而steady_clock不可，因前者纪元为posix时间、后者为系统启动时刻；需绝对时间用system_clock，需单调间隔用steady_clock。
system_clock 能转成 time_t，steady_clock 不能
这是最直接、最不可绕开的差异。如果你需要把时间点转成 std::time_t（比如传给 localtime_s、strftime 或写入日志文件名），只能用 system_clock。steady_clock::to_time_t() 根本不存在，编译直接报错：no member named 'to_time_t'。
原因很简单：system_clock 的纪元是 1970-01-01 00:00:00 UTC（POSIX epoch），和 time_t 定义一致；而 steady_clock 的纪元是系统启动时刻，没有现实时间意义，无法映射。
- 要生成
screenshot_20260727_231205.jpg这类文件名 → 必须用system_clock - 要记录“本次函数执行耗时 12.3ms” → 用
steady_clock更安全 - 混用两者做减法（如
steady_clock::now() - system_clock::now()）→ 编译失败，类型不兼容
system_clock 可能回拨，steady_clock 绝对单调
用户手动改系统时间、NTP 同步触发时间校正、虚拟机暂停后恢复——这些都会让 system_clock::now() 返回值变小（回拨）。而 steady_clock 基于硬件计数器（如 CLOCK_MONOTONIC），只增不减。
后果很实际：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 用
system_clock做超时判断：如果系统时间被往回调了 5 秒，你的 10 秒超时可能立刻触发 - 用
steady_clock做动画帧间隔：哪怕用户调时间，帧率依然稳定 - 分布式系统中靠
system_clock排序事件 → 可能出现逻辑时间倒流，引发状态不一致
high_resolution_clock 不是独立时钟，而是别名
high_resolution_clock 在不同标准库实现中指向不同底层时钟：
- MSVC（Visual Studio）：等价于
steady_clock - libstdc++（GCC）：等价于
system_clock - libc++（Clang）：取决于配置，可能任选其一
这意味着你写 high_resolution_clock::now()，行为其实不确定。它可能单调，也可能被调时间影响；可能支持 to_time_t()，也可能不支持。生产代码里，除非你明确约束了编译器和标准库版本，否则应避免直接依赖它。
更稳妥的做法是：需要绝对时间 → 显式用 system_clock；需要可靠间隔 → 显式用 steady_clock。
精度 ≠ 稳定性，别被“高分辨率”误导
有人看到 steady_clock::period 是 std::nano 就以为它一定比 system_clock 更“准”。但实际精度取决于硬件和 OS 支持：
- 在老旧硬件或某些虚拟化环境中，
steady_clock的实际分辨率可能是毫秒级 -
system_clock在 Windows 上通过GetSystemTimePreciseAsFileTime也能达到 100ns 级别 - 真正关键的是“是否单调”，而不是“标称精度”。测性能、控超时，单调性永远优先于纳秒级数字
一个容易被忽略的点：即使两个时钟都返回纳秒级数值，只要其中一个可能跳变，它就不适合做差值计算。稳，比快重要得多。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
