应使用 std::chrono::steady_clock 获取毫秒级时间差，因其单调不回退；用 duration_cast 转换，避免混用时钟类型；推荐 RAII 计时器类，构造记录起点、析构自动计算，elapsed() 返回 duration 保证精度与灵活性。
用 std::chrono::steady_clock 获取毫秒级时间差
直接用 std::chrono::system_clock 会有时区/系统时间跳变风险，steady_clock 才是唯一适合计时的时钟：它单调、不回退、不响应系统时间调整。毫秒精度不需要手动除法，直接用 duration_cast 转换即可。
常见错误是写成 duration_cast<milliseconds>(end - start).count()</milliseconds> 却忘了 start 和 end 必须是同一时钟类型 —— 混用 system_clock 和 steady_clock 会导致编译失败或未定义行为。
- 始终用
auto start = steady_clock::now();开始，auto end = steady_clock::now();结束 - 转换时明确指定目标单位：
duration_cast<milliseconds>(end - start)</milliseconds>，不要依赖隐式转换 - 如果只需要整数毫秒，调用
.count()；若需浮点毫秒（比如保留小数），用duration_cast<duration milli>>(end - start).count()</duration>
封装成 RAII 计时器类，避免手动调用 end
手写两次 now() 容易漏掉结束时间或顺序颠倒，尤其在有分支、异常或提前 return 的函数里。RAII 是最自然的解法：构造时记录起点，析构时自动计算并输出（或存入成员变量）。
注意别把耗时打印逻辑写死在析构函数里——这会让类无法复用。更好的做法是提供 elapsed() 方法，让用户决定何时读取、如何使用结果。
立即学习“C++免费学习笔记（深入）”；
- 类内只存
time_point<steady_clock></steady_clock>成员，不存milliseconds值（避免过早截断精度） - 构造函数加
explicit防止意外隐式转换 -
elapsed()返回duration<double milli></double>比long long更灵活，支持后续做比较或累加
在 Windows 上遇到 QueryPerformanceCounter 级别精度需求？不用换
有人看到文档说 steady_clock 在 Windows 下底层用 QueryPerformanceCounter，就以为“不够快”或“要自己封装”。其实完全没必要：C++11 起所有主流编译器（MSVC / Clang / GCC）在 Windows 上对 steady_clock::now() 的实现就是 QPC，分辨率通常在 10–15 微秒，远高于毫秒需求。
真正要注意的是：别在循环里高频调用 now() 做微基准测试——函数调用本身开销可能接近 100ns，测几微秒级操作会失真。毫秒级计时完全不受影响。
- 确认是否真需要亚毫秒精度？如果只是测函数执行、网络请求、文件读写，
steady_clock够用 - 避免用
clock()或time()：前者是 CPU 时间且精度低，后者是秒级系统时间 - Linux 下同理，
steady_clock底层通常是clock_gettime(CLOCK_MONOTONIC)，无需干预
实操示例：一个可立即复制粘贴的轻量计时器
下面这个类不依赖第三方库，C++11 起可用，编译即跑：
class Timer {
public:
explicit Timer() : start_(steady_clock::now()) {}
<pre class="brush:php;toolbar:false;">template<typename T = double>
auto elapsed() const {
auto delta = steady_clock::now() - start_;
return duration_cast<duration<T, milli>>(delta).count();
}private:
time_point
// 使用： Timer t; do_something_heavy(); printf("took %.2f ms\n", t.elapsed()); // 输出类似 "took 12.34 ms"
如果项目禁用 RTTI 或异常，这个类依然安全；但若需线程安全（比如多个线程共用一个 Timer 实例），就得加 mutable mutex 和锁——不过绝大多数场景下，每个计时器都该是局部、单线程使用的。
最容易被忽略的一点：别在类里自动打印或日志——看似方便，实则破坏单一职责，也让单元测试和性能压测难以捕获数值。
