推荐用 std::chrono::steady_clock 获取毫秒级单调时间戳（程序启动起算），用 std::chrono::system_clock 获取 Unix 毫秒时间戳（UTC，自1970年起），二者语义不同不可混用。
用 std::chrono::steady_clock 获取毫秒级时间戳（推荐）
现代 C++ 最可靠的方式是使用 std::chrono::steady_clock，它不随系统时钟调整跳变，适合做时间差或单调递增计数。获取当前毫秒值本质是「从纪元起的毫秒数」，但注意：steady_clock 的纪元是实现定义的（通常为程序启动或系统启动），不能直接当“系统时间”用；若你真正需要的是“自 Unix 纪元以来的毫秒数”，得换方案。
实操建议：
- 用
std::chrono::steady_clock::now().time_since_epoch().count()得到纳秒级整数，再除以 1'000'000 转毫秒（注意类型溢出风险，推荐long long） - 更安全写法：
std::chrono::duration_cast<:chrono::milliseconds>(std::chrono::steady_clock::now().time_since_epoch()).count()</:chrono::milliseconds> - 避免用
system_clock直接取毫秒——它可能因 NTP 调整回拨，导致返回值突降
用 std::chrono::system_clock 获取 Unix 毫秒时间戳（需转本地时间）
如果你要的是类似 JavaScript Date.now() 那种“自 1970-01-01 00:00:00 UTC 起的毫秒数”，必须用 std::chrono::system_clock，并确保时区处理正确（它返回的是 UTC 时间）。
常见错误现象：直接调 system_clock::to_time_t 再用 localtime，结果被本地时区偏移污染，毫秒值没错，但后续做时间比较或网络传输时容易误以为是本地时间。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 获取毫秒值本身只需：
std::chrono::duration_cast<:chrono::milliseconds>(std::chrono::system_clock::now().time_since_epoch()).count()</:chrono::milliseconds> - 该值始终是 UTC 毫秒数，和本地
TZ环境变量无关，可直接用于日志打点、API 时间戳等场景 - 不要试图用
std::chrono::zoned_time（C++20）去“转成本地毫秒”——毫秒数值本身没有时区，加时区只是格式化显示的事
Windows 下用 GetTickCount64() 的局限性
Windows API 的 GetTickCount64() 返回系统启动后毫秒数，轻量、无锁、高精度（实际分辨率约 10–16ms），但它不是“系统当前时间”，也不跨重启连续，且在系统运行超 49.7 天后会绕回（虽然 64 位版不会溢出，但语义仍是 uptime）。
使用场景仅限：进程内计时、超时判断、性能采样间隔。不能用于记录事件绝对时间或与外部系统对时。
实操建议：
- 头文件需包含
<windows.h>，链接默认库，无需额外配置 - 返回值类型是
ULONGLONG，直接赋给uint64_t即可 - 别和
GetTickCount()（32 位版）混用，后者在约 49.7 天后归零，极易引发逻辑错误
Linux/macOS 下避免用 clock_gettime(CLOCK_MONOTONIC) 手动封装
虽然 POSIX 提供了高精度单调时钟，但 C++11 起 std::chrono::steady_clock 在主流编译器（GCC/Clang）底层就映射到 CLOCK_MONOTONIC，手动调用反而增加可移植性负担和错误概率（比如忘记检查返回值、误用 CLOCK_REALTIME）。
容易踩的坑：
- 用
CLOCK_REALTIME替代CLOCK_MONOTONIC：前者受系统时间修改影响，两次调用可能返回更小的值 - 忽略
clock_gettime的返回值（失败时为 -1），导致未初始化的timespec结构体被读取 - 把秒+纳秒字段简单相加却不考虑纳秒进位（如 1.5 秒 = 1 秒 + 500'000'000 纳秒，不是 1500 毫秒）
真正要注意的其实是精度来源和语义差异：毫秒值本身不难取，难的是搞清你要的是 uptime、UTC 时间戳，还是单调差值。选错时钟类型，后期排查时间跳跃或负延时会非常痛苦。
