最可靠方法是用std::chrono::system_clock获取毫秒部分：auto now = std::chrono::system_clock::now(); auto ms = std::chrono::duration_cast<std::chrono::milliseconds>(now.time_since_epoch()).count() % 1000；必须先转为milliseconds再取余，因底层tick单位平台相关。
用 std::chrono::system_clock 获取毫秒部分最可靠
直接取系统时间的毫秒数，别碰 time() 或 gettimeofday() 这类秒级接口——它们不提供毫秒精度。C++11 起，std::chrono::system_clock 是标准、跨平台、无歧义的选择。
关键点是：先获取当前时间点，再转换为毫秒 duration，最后对 1000 取余：
auto now = std::chrono::system_clock::now(); auto ms = std::chrono::duration_cast<std::chrono::milliseconds>(now.time_since_epoch()).count() % 1000;
-
time_since_epoch()返回从纪元起的总 tick 数，类型是duration -
duration_cast转成milliseconds后count()才是整数毫秒值 - 必须用
% 1000，不能靠截断小数——system_clock的底层 tick 可能不是毫秒（比如 Windows 上常是 100ns），直接 cast 再取余才安全
为什么不用 localtime() + tm 结构体
tm 里没有毫秒字段，tm_sec 最多到 59（忽略闰秒），tm_msec 根本不存在。有人试图用 gettimeofday() 填充 tm，但那是 Unix 扩展、非标准，且依然要自己算毫秒部分，徒增可移植性风险。
- Windows 下
localtime_s()也不带毫秒支持 - 即使你用
strftime()格式化出%f（微秒），它依赖 C 库实现，C++ 标准不保证该格式符存在 - 绕开
chrono直接操作 C 时间 API，大概率在不同编译器或平台下行为不一致
注意 system_clock::now() 的实际精度
标准只要求 system_clock “尽可能接近真实时间”，不保证硬件级精度。实测中：
立即学习“C++免费学习笔记（深入）”；
- Linux（glibc + x86_64）通常能到微秒级，
now()调用开销约 20–50 ns - Windows（MSVC）底层调用
QueryPerformanceCounter，理论可达纳秒，但受system_clock实现封装影响，稳定返回毫秒级已足够 - 如果真需要更高频采样（比如性能打点），应改用
steady_clock，但它不对应日历时间，不能用于“当前时间”的语义
常见错误：把 time_point 当成毫秒值直接用
下面这段代码是错的：
auto now = std::chrono::system_clock::now(); int ms = now.time_since_epoch().count(); // 错！单位未知，可能是纳秒或 100ns
错误根源在于没做 duration_cast。不同平台 system_clock::period 不同：
- Clang/libc++：常用
nanoseconds - MSVC：常用
nanoseconds或100nanoseconds - 直接
count()取值再 % 1000，结果完全不可预测
真正要记住的只有一句：毫秒部分 = duration_cast<milliseconds>(tp.time_since_epoch()).count() % 1000。其他路径，要么不标准，要么埋雷。
