应使用 std::chrono::steady_clock 获取稳定时间戳，其 time_since_epoch() 返回从时钟起点开始的持续时间，count() 得毫秒数；测耗时需同钟两次 now() 后 duration_cast 相减，避免混用时钟或直接 count()。
直接用 std::chrono::steady_clock 或 std::chrono::high_resolution_clock，别碰 std::chrono::system_clock 做计时——它可能被系统时间调整拖偏。
怎么拿到当前毫秒数（从某个稳定起点开始）
最常用也最安全的方式是用 steady_clock 获取一个相对时间戳，再转成毫秒整数：
auto now = std::chrono::steady_clock::now();
auto ms = std::chrono::duration_cast(now.time_since_epoch()).count();
注意：time_since_epoch() 返回的是从时钟“起始点”开始的持续时间，不是 Unix 时间戳；steady_clock 不受系统时间修改影响，适合测间隔；count() 返回的是底层 tick 数，类型依赖实现（通常是 long long）。
- 如果只需要两次调用之间的毫秒差，直接相减再转
milliseconds 更准，避免溢出或精度损失
- 不要用
system_clock::to_time_t 再转毫秒——多此一举且引入时区/闰秒等干扰
- Windows 上
high_resolution_clock 通常就是 steady_clock 的别名；Linux 上它可能映射到 CLOCK_MONOTONIC，但标准不保证，所以优先显式写 steady_clock
怎么测一段代码执行耗时（精确到毫秒）
这是 chrono 最典型的用途，关键在「同一时钟、两次 now()、用 duration_cast 截断」：
auto start = std::chrono::steady_clock::now();
// ... your code here ...
auto end = std::chrono::steady_clock::now();
auto ms = std::chrono::duration_cast(end - start).count();
常见错误：
- 混用不同 clock（比如 start 用
steady_clock，end 用 system_clock），结果未定义
- 用
auto ms = (end - start).count() 直接取底层 tick 数——你不知道单位是纳秒还是微秒，跨平台不可靠
- 对短于 1ms 的操作反复测单次，结果受调度、缓存预热等干扰大；应循环多次取平均，或用
nanoseconds 级别再四舍五入
为什么 high_resolution_clock 不推荐直接用
标准只要求它是“实现提供的最高分辨率时钟”，但没规定它是否单调、是否稳定。实际中：
- MSVC 里它常是
steady_clock 的 typedef，但只是巧合
- 某些旧版 libstdc++ 把它映射到
system_clock，一旦 NTP 调整时间，前后两次 now() 可能倒退
- Clang/libc++ 文档明确说：「
high_resolution_clock 是别名，不保证单调性；需要可靠计时请用 steady_clock」
所以除非你在写 micro-benchmark 且已确认平台行为，否则一律用 steady_clock。
毫秒级足够？那得看你要干啥
普通日志打点、接口超时判断、UI 响应延迟监控，毫秒完全够用。但如果是：
- 高频交易或硬件同步：得用
nanoseconds，并确认 CPU 支持 RDTSC 或 TSC 稳定
- 长时间运行（比如几天）：
steady_clock::duration::max() 在 64 位系统上约支持 292 年，毫秒计数器本身不会溢出，但你自己用 int 存就可能
- 跨进程/跨机器时间比对：
steady_clock 没意义，必须回退到 system_clock + NTP 校准，且接受 ±10ms 误差
真正容易被忽略的是：steady_clock::now() 本身有开销（通常几十纳秒），在 tight loop 里频繁调用会污染测量结果——测小函数时，记得把调用开销单独扣掉或用基准法抵消。
