std::chrono::steady_clock 不能直接转成“年月日时分秒”，因为它不关联日历时间，其 epoch 是实现定义的（如系统启动时刻），无 UTC 或本地时间语义；正确做法是仅用于测间隔，需绝对时间时必须用 system_clock。
steady_clock 为什么不能直接转成“年月日时分秒”
std::chrono::steady_clock 是单调递增的时钟，不随系统时间调整而跳变，适合测间隔、超时等场景。但它**不关联日历时间**，起点是实现定义的（比如系统启动后某个时刻），所以 steady_clock::now() 返回的 time_point 无法直接格式化为本地或 UTC 时间字符串。
如何正确获取当前 steady_clock 时间点（并避免隐式转换错误）
获取采样值本身很简单，但常见错误是误用 system_clock 的转换逻辑，或试图对 steady_clock::time_point 调用 std::chrono::system_clock::to_time_t —— 这会编译失败。
- 正确写法：只调用
steady_clock::now()获取time_point - 若需纳秒级精度，显式转换到
nanoseconds：auto tp = steady_clock::now(); auto ns = duration_cast<nanoseconds>(tp.time_since_epoch()).count();
- 不要尝试
tp.time_since_epoch().count()后直接除以 1e9——不同平台底层周期可能不是纳秒，应始终用duration_cast - 注意：
steady_clock的period可能是ratio（纳秒），也可能是ratio（微秒），取决于标准库实现（如 libstdc++ 和 libc++ 行为略有差异）
什么时候该用 steady_clock，什么时候不该用
它不是“更准”的时间源，而是“更稳”的时间源。关键区别在用途：
- ✅ 适合：计时器、超时控制、性能打点、循环节拍（如游戏帧间隔）
- ❌ 不适合：记录日志时间戳、生成文件名中的时间、与外部系统做时间比对（如 HTTP Date 头）
- ⚠️ 风险点：跨进程/跨机器传递
steady_clock值无意义，它没有全局一致性 - ⚠️ 兼容性提示：C++11 起保证存在，但某些嵌入式平台或旧编译器（如早期 MSVC 2013）的
steady_clock::is_steady可能返回false，建议运行时检查
和 system_clock 混用的典型陷阱
有人想“先拿 system_clock 当前值，再换算成 steady_clock”，这是错的——两者起点不同、速率也可能有微小偏差（虽然通常可忽略），且标准不保证可逆转换。
立即学习“C++免费学习笔记（深入）”；
- 编译期就会报错：
system_clock::time_point(tp)或steady_clock::time_point(tp)都不合法，除非显式提供转换函数（而标准没提供） - 唯一安全的跨时钟操作是：都转成
duration自 epoch 起的整数，再做差值比较（但语义仅限于“经过多久”，不能还原成绝对时刻） - 如果真需要关联绝对时间 + 单调性，常见做法是：启动时记录一对
system_clock::now()和steady_clock::now()，后续用steady_clock增量推算system_clock近似值（需注意 drift）
steady_clock 打点和 system_clock 时间戳，导致时间线无法对齐；一旦涉及分布式或重放分析，这种混用会让问题排查成本翻倍。 
