应使用 std::chrono::system_clock::now() 配合 duration_cast 转换为毫秒，因其 epoch 与 Unix 纪元对齐且行为与 JavaScript 的 Date.now() 一致；steady_clock 不适用，因其不反映真实世界时间；time() 和 Windows API 均因缺乏 UTC 对齐和纪元一致性而不可替代。
为什么不能直接用 time() 替代 Date.now()
time() 返回的是秒级时间戳（time_t），而 JavaScript 的 Date.now() 返回毫秒级整数，从 Unix 纪元（1970-01-01T00:00:00Z）开始算起。直接调用 time(nullptr) 会丢掉毫秒精度，导致和 JS 端时间对不上——尤其在做前后端时间同步、日志打点或动画帧控制时，误差可能达 999ms。
C++11 起推荐用 std::chrono::steady_clock 还是 system_clock？
必须用 std::chrono::system_clock。因为 steady_clock 是单调递增的，不对应真实世界时间（比如系统时间被 NTP 调整时它不变），而 Date.now() 明确依赖系统当前 UTC 时间。虽然 system_clock::now() 可能受系统时钟跳变影响，但它和 JS 的 Date.now() 行为一致。
-
system_clock的 epoch 和 Unix 纪元对齐（C++11 起标准保证） - 用
duration_cast<:milliseconds></:milliseconds>转换，避免整数截断错误 - 不要用
time_point::time_since_epoch().count()直接取值——类型依赖平台（如 Windows 下可能是 100ns 单位）
一行可移植的实现（C++11 及以上）
最简、可靠、跨平台的写法：
auto now_ms = std::chrono::duration_cast<std::chrono::milliseconds>(
std::chrono::system_clock::now().time_since_epoch()).count();
说明：
立即学习“Java免费学习笔记（深入）”；
- 返回
long long类型，能覆盖到公元 2242 年左右，和 JS 的Date.now()数值范围基本兼容 - Windows、Linux、macOS 下行为一致；Clang/GCC/MSVC 均支持
- 如果项目用 C++14+，可简化为
std::chrono::time_point_cast<:chrono::milliseconds>(std::chrono::system_clock::now()).time_since_epoch().count()</:chrono::milliseconds>，但可读性没提升，没必要
常见踩坑点：Windows 上 GetTickCount64() 或 QueryPerformanceCounter() 能替代吗？
不能。这两个 API 都不基于 Unix 纪元：
-
GetTickCount64()从系统启动开始计时，重启就归零，且无 UTC 对齐 -
QueryPerformanceCounter()单位是硬件周期，需配合QueryPerformanceFrequency()换算，仍不指向 1970-01-01 - 即使手动加上启动时间偏移，也无法处理夏令时、NTP 调整等系统时间修正
强行套用只会让前后端时间差随系统运行时间增长而发散。
毫秒级精度本身容易，关键是“和 JS 的 Date.now() 在同一时间轴上”。只要坚持用 system_clock + duration_cast，就不需要额外判断平台或引入第三方库。
