应直接用std::chrono::milliseconds包装毫秒值构造time_point，避免先除1000截断精度；仅system_clock等有epoch的时钟适用此转换，steady_clock无业务意义；跨平台宜用int64_t替代long防溢出。
time_point 构造时别直接除 1000
毫秒值转 std::chrono::time_point 最常见的错误，是先用 long 除以 1000 得到秒数，再传给 seconds 构造器——这会截断毫秒部分，丢失精度。
正确做法是让 chrono 类型自己处理单位转换：
- 用
std::chrono::milliseconds包装原始毫秒值（自动支持隐式转换） - 再通过
time_point的构造函数或time_point_cast转为目标时钟类型 - 如果目标时钟是
system_clock，可直接构造；若是steady_clock，注意它不对应绝对时间，不能这么转
示例：
long ms = 1712345678901L;
auto tp = std::chrono::system_clock::time_point{std::chrono::milliseconds{ms}};
system_clock 和 steady_clock 的区别必须分清
system_clock 表示墙上时间（wall-clock time），有 epoch（通常是 1970-01-01），能和 time_t 互转；steady_clock 是单调递增的计时器，没有固定 epoch，也不代表真实时间。
立即学习“C++免费学习笔记（深入）”；
所以只有 system_clock（或 file_clock 等有 epoch 的时钟）才适合把毫秒时间戳转成有意义的 time_point：
- 用
steady_clock构造time_point并传入毫秒值，结果无业务含义 - 若你拿到的是 Unix 时间戳毫秒值（如来自 HTTP API 或数据库），只能转给
system_clock - 跨时钟转换要用
time_point_cast，但前提是源和目标时钟有可比性（比如都基于纳秒计数）
跨平台时注意 long 的位宽问题
Windows 上 long 是 32 位，而毫秒级 Unix 时间戳在 2038 年后就会溢出；Linux/macOS 通常为 64 位，但标准不保证。实际中应避免依赖 long 存毫秒值。
更稳妥的做法：
- 用
int64_t或std::chrono::milliseconds::rep接收原始值 - 构造
milliseconds时，模板推导会自动适配底层整型，无需强转 - 如果输入来自 C API（如
GetSystemTimeAsFileTime），注意其单位是 100 纳秒，需先除 10000 得到毫秒，或直接构造nanoseconds
从 time_point 取毫秒值要小心舍入方向
反向操作（time_point → 毫秒整数）容易踩坑：直接用 duration_cast<milliseconds></milliseconds> 再调 .count() 是向下取整，可能和预期不符。
- 若需四舍五入到最接近的毫秒，先加 500 微秒再 cast：
duration_cast<milliseconds>(tp.time_since_epoch() + 500us)</milliseconds> - 若需向上取整（如计算超时剩余时间），加
999us后再 cast - 注意
time_since_epoch()返回的是相对于该时钟 epoch 的duration，不同 clock 的 epoch 不同，不能混用
真正难的不是写对一行构造，而是确认这个毫秒值到底属于哪个时间系统、有没有时区偏移、是否已考虑闰秒（system_clock 不考虑闰秒，这点常被忽略）。
