std::chrono::system_clock::now() 不保证纳秒精度，因其底层依赖平台实现：Linux 通常支持纳秒，Windows 常为 15–16ms；类型为 nanoseconds 不代表实际分辨率，真实精度需实测或查文档；推荐 Linux 下直接调用 clock_gettime(CLOCK_REALTIME, &ts) 获取纳秒级 Unix 时间戳。
为什么 std::chrono::system_clock::now() 返回的不是纳秒精度？
直接调用 std::chrono::system_clock::now() 得到的是 time_point，但它底层分辨率取决于平台实现：Linux 上通常是纳秒，Windows 上常见是 15–16ms（基于 GetSystemTimeAsFileTime）。即使类型是 nanoseconds，不代表实际能读到纳秒级变化。
关键判断：不要依赖 system_clock 的 period 类型来推断真实精度；必须查文档或实测抖动。
- 用
std::chrono::high_resolution_clock::now()更接近硬件时钟，但它是“相对时间”，不保证对应 Unix 时间戳（即可能不等于 1970-01-01 起的秒数） - 若必须是 Unix 时间 + 纳秒，得把
high_resolution_clock和system_clock对齐一次（通常在程序启动时做一次校准） - Linux 下可绕过 C++ 标准库，直接调用
clock_gettime(CLOCK_REALTIME, ...)—— 它明确返回纳秒级 Unix 时间
Linux 下用 clock_gettime 获取纳秒级 Unix 时间
这是最直接、可验证的方式。它返回自 Unix epoch 起的秒 + 纳秒，且内核保证 CLOCK_REALTIME 是单调递增（除非手动调时）。
注意：clock_gettime 在 glibc 中默认可用，但需链接 -lrt（CMake 中加 target_link_libraries(your_target rt)）。
立即学习“C++免费学习笔记（深入）”；
#include <time.h>
#include <inttypes.h>
<p>struct timespec ts;
if (clock_gettime(CLOCK_REALTIME, &ts) == 0) {
uint64_t nanos = static_cast<uint64_t>(ts.tv_sec) * 1000000000ULL + ts.tv_nsec;
// nanos 就是 Unix 纳秒时间戳
}
-
ts.tv_sec是time_t类型，32 位系统可能溢出（2038 年问题），建议统一用int64_t或uint64_t存储结果 -
ts.tv_nsec范围是 [0, 999999999]，不会越界，但相加时务必用ULL后缀防止整型溢出 - 该调用开销极低（vDSO 优化后通常不到 10ns），比多次
std::chrono操作更轻量
跨平台方案：用 std::chrono 校准 + high_resolution_clock 增量
如果必须支持 Windows 且要纳秒级 Unix 时间，只能接受一次校准误差（通常 system_clock 获取一个 Unix 时间点，同时记录此时的 high_resolution_clock::now()；之后所有时间都基于后者差值推算。
auto base_sys = std::chrono::system_clock::now();
auto base_hrc = std::chrono::high_resolution_clock::now();
// 后续任意时刻：
auto now_hrc = std::chrono::high_resolution_clock::now();
auto delta = now_hrc - base_hrc;
auto unix_nanos = std::chrono::duration_cast<std::chrono::nanoseconds>(
base_sys.time_since_epoch() + delta
).count();
- 校准只做一次，避免累积 drift；但若系统时间被 NTP 或用户修改，
base_sys就失效了（此时应重新校准） - Windows 下
high_resolution_clock通常基于QueryPerformanceCounter，精度可达 ~100ns，但不能直接映射到 Unix 时间 - 这个方法的“纳秒”是逻辑上的，实际分辨率仍受限于
high_resolution_clock的最小 tick（可用high_resolution_clock::period::den查）
常见错误：把 time_point::time_since_epoch().count() 当成纳秒
很多人写 auto t = system_clock::now().time_since_epoch().count() 就以为是纳秒——错。它返回的是该 clock 自身 epoch 起的 tick 数，单位由 system_clock::period 决定，而该 period 在不同 STL 实现中差异极大：
- libstdc++（GCC）：常为
nanoseconds，但底层仍是微秒级 syscall，高位恒为 0 - MSVC：
system_clock::period是1/10^7秒（100ns），但实际值每 15ms 才更新一次 - Clang + libc++：行为类似 libstdc++，但需确认编译目标平台
真正可靠的做法永远是：先确认你拿到的数值是否随每次调用变化（写个循环打 100 次日志看 count() 是否变），再决定能否用于性能分析或定时场景。
Unix 时间戳的“纳秒级”意义在于顺序和差值精度，不是每个 bit 都有效——别被类型名骗了。
