最可靠的是 std::chrono::steady_clock，它不受系统时间调整影响，适合性能测量；避免使用 high_resolution_clock（可能退化）和 clock()（测 CPU 时间且平台差异大）。
用 std::chrono 测量毫秒级精度最可靠
Windows 上用 GetTickCount64() 或 Linux 用 clock_gettime(CLOCK_MONOTONIC, ...) 都行，但跨平台、类型安全、不易出错的首选是 std::chrono。它基于编译器和系统提供的高精度时钟源，C++11 起就稳定可用。
关键不是“怎么调用”，而是“选对时钟类型”：std::chrono::steady_clock 不受系统时间调整影响，适合测耗时；std::chrono::system_clock 对应墙上时间，不适合性能测量。
常见错误是直接用 std::chrono::high_resolution_clock —— 它在某些平台（如旧版 MSVC）可能退化为 system_clock，导致结果跳变。稳妥起见，统一用 steady_clock。
示例：
立即学习“C++免费学习笔记（深入）”；
#include <chrono> auto start = std::chrono::steady_clock::now(); // your code here auto end = std::chrono::steady_clock::now(); auto ms = std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count();
避免 clock() 和 CLOCKS_PER_SEC 的陷阱
clock() 返回的是 CPU 时间（进程占用的处理器时间），不是真实经过时间（wall-clock time）。多线程下它只累加各线程的 CPU 使用时间，结果远大于实际耗时；如果代码大量阻塞（如 sleep、IO 等待），clock() 几乎不增长，测出来接近 0。
另一个坑是 CLOCKS_PER_SEC 并非标准规定为 1000000（微秒），POSIX 要求至少 1000000，但 Windows 上 VC++ 实现为 1000 —— 这意味着你写 clock() / CLOCKS_PER_SEC 得到的是秒，但除法前没转成 double 就会整数截断，精度全丢。
除非你明确要测 CPU 时间且接受平台差异，否则别碰 clock()。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
微秒/纳秒级测量要注意时钟开销和抖动
单次 steady_clock::now() 调用本身有开销（通常几十纳秒），如果你测的是几纳秒的函数（比如一个空循环或简单算术），测量值基本是噪声。这时需要多次运行取平均，或用 std::chrono::nanoseconds 配合循环计时再除次数。
但注意：编译器可能优化掉“无副作用”的空循环。加 volatile 或把结果写入 asm volatile("" ::: "memory") 可阻止优化，不过这已超出纯 C++ 范畴。
更现实的做法是：确认你要测的代码块本身耗时 ≥ 1 微秒，再用 nanoseconds；否则直接用 microseconds 更稳。
性能敏感场景还要关掉频率调节（如 Linux 的 cpupower frequency-set -g performance），否则 CPU 动态降频会让结果波动极大。
封装成 RAII 工具类能防漏测和简化日志
手动写两行 now() 容易漏掉结束点，尤其函数提前 return 或抛异常时。用 RAII 自动析构记录结束时间更健壮。
一个轻量封装示例：
struct Timer {
using clock = std::chrono::steady_clock;
clock::time_point start_;
Timer() : start_(clock::now()) {}
~Timer() {
auto us = std::chrono::duration_cast<std::chrono::microseconds>(
clock::now() - start_).count();
std::cout << "elapsed: " << us << " μs\n";
}
};
// 使用：
{
Timer t;
// your code
} // 自动打印耗时
注意：不要在构造函数里打日志、不要捕获异常后吞掉——否则异常路径下测不到时间，还可能掩盖问题。
测执行时间最常被忽略的，其实是“是否真的在测目标代码”。宏定义展开、内联函数、编译器优化（-O2 下整个块被删）、调试器断点暂停，都会让结果失真。实测前先关优化（-O0）、确认符号未被 strip、用 volatile 固定关键变量，比换时钟类型更重要。
