应优先选std::chrono::steady_clock测间隔，因它单调递增、不受系统时间调整影响；需绝对时间戳时才用system_clock。两者精度和移植性有平台差异，转换须用duration_cast。
用
还是
？
返回的是挂钟时间（即系统时间），受 NTP 调整、手动改时影响，不适合测间隔；
才是真正单调递增、不受系统时间扰动的时钟，适合纳秒级计时。但注意：
的 epoch 是未指定的，不能直接当“时间戳”用（比如存日志、传给其他系统）。
如果你要记录“某事件发生时的绝对时间”，必须用
，哪怕它可能跳变
如果你要测函数执行耗时、做超时判断，无条件选
Linux 上
通常基于
，
基于
，这是内核层面的根本区别
能否直接拿到纳秒？
能，但得手动转换——
默认精度由实现决定（GCC 通常为微秒，Clang 可能是纳秒），不能直接假设。必须显式转成纳秒单位：
返回的是从 epoch（1970-01-01 00:00:00 UTC）开始的
，类型依赖编译器和标准库
是安全转换的唯一方式，强制截断或补零，不推荐用
或隐式转换
返回的是
类型的纳秒整数，不是浮点，避免精度丢失
Linux 下用
更准？
在 glibc 2.17+ 和较新内核上，
底层就是调
，所以两者纳秒精度一致。但直接调系统 API 有几点实际差异：
C知道
CSDN推出的一款AI技术问答工具
下载
可以绕过 C++ 标准时钟封装，少一次函数跳转，性能略高（微秒级场景才值得考虑）
它返回的是
，字段
+
，拼起来就是纳秒时间戳，无类型转换开销
但移植性差：Windows 没这接口，得切到
或
如果你已在用 C++11 以上，没理由弃
改手写 syscall，除非 profiling 真实测出它是瓶颈
跨平台纳秒时间戳的常见坑
Windows 上
在 MSVC 2015–2019 中默认只有 100ns 精度（对应
），不是真纳秒；即使 cast 到
，低位始终是 0
macOS 上
用
，再按
换算，但最终映射到
仍有约 1µs 误差
所有平台都需注意：纳秒值极大（2024 年约
），存成
没问题，但别用
（32 位平台会溢出）
日志或网络传输时，别直接打
对象——它不可读也不可序列化，务必转成整数纳秒或 ISO8601 字符串
纳秒级时间戳听着精确，但真正难的是“对齐”：不同线程读的时间是否可比、跨进程通信时要不要加时钟同步、日志里混用
和
会不会导致时间倒流……这些细节比怎么取值更常引发线上问题。
立即学习
“
C++免费学习笔记（深入）
”；
std::chrono::steady_clockstd::chrono::system_clockstd::chrono::system_clockstd::chrono::steady_clocksteady_clocksystem_clocksteady_clocksteady_clockCLOCK_MONOTONICsystem_clockCLOCK_REALTIMEsystem_clock::now()system_clock::time_point
auto tp = std::chrono::system_clock::now();
auto ns = std::chrono::duration_cast(
tp.time_since_epoch()
).count();
tp.time_since_epoch()durationduration_caststatic_cast.count()long longclock_gettime(CLOCK_REALTIME, ...)std::chrono::system_clock::now()clock_gettime(CLOCK_REALTIME, ...)clock_gettimestruct timespectv_sectv_nsecGetSystemTimeAsFileTimeQueryPerformanceCountersystem_clocksystem_clockFILETIMEnanosecondssystem_clockmach_absolute_time()mach_timebase_infoCLOCK_REALTIME1710000000000000000int64_tunsigned longtime_pointsteady_clocksystem_clock