最轻量、标准、跨平台获取毫秒级时间戳的方式是 std::chrono::system_clock::now() 配合 duration_cast 转换，直接获得自 unix epoch 起的毫秒数，无需时区处理或系统 api 依赖。
用 std::chrono::system_clock::now() 获取毫秒级时间戳
最轻量、标准、跨平台的方式是直接用 C++11 起引入的 std::chrono。它不依赖系统 API，也不需要处理时区转换，拿到的就是 UTC 时间点对应的纳秒级精度值，转成毫秒或秒只是一次除法。
常见错误是试图用 time(nullptr) 或 gettimeofday() ——前者只能到秒，后者非标准且在 Windows 上不可用；还有人误以为 system_clock::to_time_t() 是必须步骤，其实绕一圈转成 time_t 再转回来纯属多余。
-
system_clock::now()返回的是time_point，不是整数，不能直接打印或存储 - 要转成毫秒时间戳（常用作日志、网络请求 ID、缓存 key），用
.time_since_epoch().count() / 1000000（毫秒）或/ 1000（微秒） - 注意：返回值类型是
duration::rep，通常是long long，但别硬写long long，用auto或duration_cast更安全
auto now = std::chrono::system_clock::now();
auto ms = std::chrono::duration_cast<std::chrono::milliseconds>(
now.time_since_epoch()).count();
// ms 是 long long 类型的毫秒时间戳（自 Unix epoch 起）
为什么不用 time() 或 gettimeofday()
time(nullptr) 只能返回秒级整数，丢失毫秒信息；gettimeofday() 在 Windows 上没有原生实现，MSVC 需要额外兼容层（比如通过 GetSystemTimeAsFileTime 模拟），而且它的 struct timeval 成员是 suseconds_t，类型和符号行为在不同平台不一致。
更隐蔽的问题是：time() 返回的是本地时区时间还是 UTC？标准没规定，实际取决于 tzset() 和环境变量，容易在容器或跨时区部署中出错。而 system_clock 明确定义为“系统实时钟”，对应 Unix epoch，无歧义。
立即学习“C++免费学习笔记（深入）”；
- Windows 下
gettimeofday()是 POSIX 兼容层，精度可能被限制在 15ms 左右（取决于系统 timer resolution） -
time()在嵌入式或精简 libc（如 musl）中可能被裁剪，system_clock只要支持 C++11 就一定可用 - 如果真需要秒级时间戳且想少敲几个字，
std::time(nullptr)没问题；但只要涉及毫秒、性能打点、去重逻辑，就该切到chrono
跨平台编译时要注意的头文件和命名空间
只需要 <chrono></chrono>，不需要 <ctime></ctime> 或 <sys></sys>。但新手常漏掉 std:: 前缀，或者把 system_clock 当成变量名直接用。
- 必须写全
std::chrono::system_clock::now()，不能只写system_clock::now()（除非用了using，但不推荐） -
duration_cast也在std::chrono命名空间里，不是全局函数 - Clang/GCC/MSVC 对 C++11
chrono支持都很稳定，但老版本 MSVC（如 VS2013）对time_since_epoch().count()的返回类型推导有 bug，建议至少用 VS2015+
精度和稳定性：别信文档写的“纳秒”
system_clock::now() 的 period 是纳秒，但底层硬件计时器精度远没那么高。Windows 默认 timer resolution 是 15.6ms，Linux 通常 1–10ms，只有用 clock_gettime(CLOCK_MONOTONIC, ...) 或启用高精度模式（如 Windows 的 timeBeginPeriod(1)）才能接近毫秒级稳定输出。
所以：如果你做的是日志打点或缓存过期，毫秒够用；但如果是高频采样（比如每毫秒测一次延迟），得考虑系统 timer resolution 的实际限制，而不是看 duration::period::num/den 算出来的理论值。
- 用
std::chrono::high_resolution_clock并不更好——它在多数实现里就是system_clock的别名，不是更高精度的钟 - 真正需要单调、高精度、不受系统时间调整影响的场景（比如性能测量），应优先考虑
steady_clock，但它不对应 Unix epoch，不能直接当时间戳用 - 时间戳本质是“某个时刻离 epoch 的偏移”，这个语义只有
system_clock提供，别为了“高精度”名字去换钟
