应使用 std::chrono::steady_clock::time_point 存储内部时间戳，因其基于单调硬件计数器，不受系统时钟调整影响；仅在与外部系统交互时才转换为 system_clock 并以 UTC ISO 8601 格式序列化。
用 std::chrono::steady_clock::time_point 存储内部时间戳更稳妥
如果你只是想记录“某次操作发生的时间”，std::chrono::system_clock 看似直观，但它受系统时钟调整影响——NTP 同步、手动改时间都会导致时间戳倒退或跳变。对日志排序、超时判断、持续时间计算这类逻辑，这是隐性炸弹。
推荐在类成员中直接存 std::chrono::steady_clock::time_point，它基于单调递增的硬件计数器，不受系统时间干扰：
class Request {
std::chrono::steady_clock::time_point m_started_at;
public:
Request() : m_started_at{std::chrono::steady_clock::now()} {}
auto elapsed() const {
return std::chrono::steady_clock::now() - m_started_at;
}
};- 不要存秒数、毫秒数等整型——丢失精度且失去类型语义
- 避免在构造函数外用
std::time(nullptr)或gettimeofday()赋值，它们返回的是 wall-clock 时间，和steady_clock不兼容 - 如果必须和外部系统（如 HTTP 头、数据库）交互，转换只发生在边界处，类内部坚持用
steady_clock
需要序列化或跨进程共享时，才考虑 system_clock + UTC
日志归档、分布式 trace ID 关联、数据库写入这些场景，时间必须可比、可解释，这时就得用能映射到真实时刻的时钟。
选 std::chrono::system_clock，但注意两点：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 构造时立刻转成
std::chrono::system_clock::time_point，别存time_t再反复转换 - 序列化前统一转为 ISO 8601 格式（如
"2024-05-22T14:30:45.123Z"），用std::chrono::time_point_cast<std::chrono::milliseconds>截断精度，避免微秒级浮点误差 - 不要依赖本地时区——一律用 UTC 输出，解析时也按 UTC 解析
别在成员里存 struct timespec 或 time_t
这些是 C 风格时间表示，进 C++ 类容易引发隐式转换、精度丢失和平台差异问题：
-
time_t在 Windows 上可能是 64 位，在旧 Linux 上可能是 32 位，2038 年问题还没彻底消失 -
struct timespec的tv_nsec字段名和单位（纳秒）容易误用成毫秒，且无法直接参与chrono运算 - 一旦成员是
time_t，你就没法用auto elapsed = now - m_created这种自然表达式，得手写差值计算
真要兼容旧接口，用私有成员存 steady_clock::time_point，提供 to_timespec() 这样的显式转换函数，而不是把 C 结构体暴露在类定义里。
注意 steady_clock 的分辨率和稳定性
虽然 steady_clock 单调，但不同平台的实际精度可能差一个数量级：
- Linux x86_64 上通常为纳秒级（
clock_gettime(CLOCK_MONOTONIC, ...)） - Windows 上
QueryPerformanceCounter可达微秒级，但某些虚拟机可能回落到毫秒 - 用
std::chrono::steady_clock::period::num / std::chrono::steady_clock::period::den查实际周期，别假设一定是纳秒
如果你的业务对抖动敏感（比如实时音频同步），光靠 steady_clock 不够，还得结合硬件时间戳或 PTP 同步，但那是另一层需求了——普通服务类代码，用好 steady_clock::time_point 成员就已覆盖绝大多数正确性要求。
