17370845950

应使用 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 里频繁调用会污染测量结果——测小函数时，记得把调用开销单独扣掉或用基准法抵消。