最可靠方法是用std::chrono::system_clock::now().time_since_epoch()配合duration_cast<milliseconds>::count()获取UTC毫秒时间戳；它跨平台、类型安全、与JavaScript/Python时间戳对齐，且避免了time_t截断和时区陷阱。
用 std::chrono 配合 std::time_t 转换最可靠
标准 C++11 及以后不直接提供“毫秒级 UTC 时间戳”这一整数类型，但能组合 std::chrono::system_clock 和 std::time_t 精确拿到自 Unix epoch 起的毫秒数（UTC）。关键在于：不能只靠 std::chrono::system_clock::now() 转成 std::time_t 再乘 1000——这会丢掉亚秒部分。
正确做法是先获取 std::chrono::system_clock::time_point，再用 time_since_epoch() 拆出毫秒计数：
auto now = std::chrono::system_clock::now();
auto ms = std::chrono::duration_cast<std::chrono::milliseconds>(
now.time_since_epoch()).count();
这个 ms 就是标准 UTC 毫秒时间戳，和 JavaScript 的 Date.now()、Python 的 time.time() * 1000 对齐。
std::chrono::system_clock 是 UTC 吗？
是的，C++ 标准明确要求 std::chrono::system_clock 表示系统实时钟（wall clock），其 epoch 是 Unix time（1970-01-01 00:00:00 UTC），且不随本地时区或夏令时调整。它底层通常调用 clock_gettime(CLOCK_REALTIME, ...)（Linux）或 GetSystemTimeAsFileTime（Windows），两者都返回 UTC 时间。
立即学习“C++免费学习笔记（深入）”；
注意：std::chrono::steady_clock 不行——它是单调递增的，不关联 UTC；std::chrono::high_resolution_clock 是别名，可能等价于 steady_clock，不可用于获取 UTC。
Windows 下用 GetSystemTimeAsFileTime 会更准吗？
不会更准，反而更麻烦。虽然 Windows 的 FILETIME 分辨率可达 100ns，但转换为毫秒 UTC 时间戳仍需减去 Windows epoch 偏移（1601-01-01 到 1970-01-01 是 11644473600 秒），再除以 10000（100ns → ms），极易出错。而 std::chrono::system_clock 在所有主流编译器（MSVC、Clang、GCC）上已对 Windows 做了正确封装，无需手动处理。
除非你有特殊需求（比如需要微秒级且跨平台一致的单调时间差），否则没必要绕开 std::chrono。
- 不要用
localtime或gmtime处理std::time_t来“校正”——system_clock已是 UTC - 避免
std::chrono::duration_cast<:chrono::milliseconds>(...).count()</:chrono::milliseconds>之前先转成std::time_t——会截断毫秒以下部分 - 如果目标是日志打点或网络协议时间字段，直接用上面的
ms.count()即可，无需格式化为字符串
跨平台编译时要注意什么？
只要使用 C++11 或更高标准（-std=c++11 及以上），std::chrono::system_clock 在 Linux、macOS、Windows（MSVC/Clang-CL/MinGW）上行为一致。但有两点容易被忽略：
- 某些嵌入式 STL 实现（如旧版 Newlib）可能未完全实现
system_clock::now()，需验证返回值是否非零 - 在 macOS 上，
system_clock::now()默认分辨率约 15ms（受mach_absolute_time底层限制），若需更高精度，得用clock_gettime(CLOCK_UPTIME_RAW, ...)——但这不是 UTC，不能用于时间戳
所以，如果你真需要 sub-millisecond UTC 精度（比如金融高频场景），C++ 标准库本身不保证，得结合平台 API 并自行做 UTC 对齐，这时毫秒级反而是更稳妥的选择。
