应优先使用 std::chrono::steady_clock 测量性能，因其跨平台、单调、不随系统时间跳变；避免误用 system_clock 或 high_resolution_clock，并防止编译器优化待测代码。
用 std::chrono::steady_clock 就够了，别自己封装
标准库的 std::chrono::steady_clock 就是为此而生的：跨平台、单调、不随系统时间调整跳变、精度足够做性能基准。Windows 上它底层调用 QueryPerformanceCounter，Linux/macOS 通常映射到 CLOCK_MONOTONIC，所有主流编译器都支持。自己用 gettimeofday、clock_gettime 或 WinAPI 手写反而容易出兼容性问题。
常见错误现象：std::chrono::system_clock 被误用——它可能因 NTP 校时或手动改系统时间而倒退或跳跃，导致基准测试结果负值或剧烈抖动；std::chrono::high_resolution_clock 在部分旧版 libstdc++（如 GCC 4.8）中只是 system_clock 的别名，不保证单调。
- 始终优先用
std::chrono::steady_clock，不是“高精度”就一定更好 - 避免依赖
high_resolution_clock，它的语义在 C++11/14 中未严格规定 - 构造时不要用
time_since_epoch()直接转整数——不同平台 epoch 基准不同，只用于相对差值
如何安全地测一段代码的耗时（纳秒级）
核心是避免编译器优化掉待测逻辑，同时防止时钟调用本身引入显著偏差。直接用 steady_clock::now() 两次取差是最轻量、最可靠的方式。
使用场景：微基准（microbenchmark），比如比较两个 memcpy 实现、测量 hash 函数单次开销。
立即学习“C++免费学习笔记（深入）”；
- 必须把待测代码放在
volatile变量读写之间，或用asm volatile("" ::: "memory")内存栅栏（GCC/Clang），否则编译器可能整个优化掉 - 不要用
auto start = steady_clock::now()然后duration_cast<nanoseconds>(end - start).count()</nanoseconds>——count()返回的是rep类型（可能是long long或int64_t），直接打印或参与计算前先确认是否溢出 - 单次测量意义不大，至少跑 3–5 次取最小值（排除缓存预热、TLB miss 等偶然干扰）
auto start = std::chrono::steady_clock::now(); // volatile dummy = do_work(); // 防优化 do_work(); auto end = std::chrono::steady_clock::now(); auto ns = std::chrono::duration_cast<std::chrono::nanoseconds>(end - start).count();
Windows 下 QueryPerformanceCounter 还有必要手撸吗？
没必要。除非你卡在非常老的环境（如 VS2010 + Windows XP），且明确测出 steady_clock 精度不足（比如只到 15ms），否则手调 QueryPerformanceCounter 只会增加维护成本和出错概率。
容易踩的坑：QueryPerformanceFrequency 返回值可能为 0（极罕见但存在），或在某些虚拟机里频率不稳定；LARGE_INTEGER 直接相减若没处理符号位，会导致巨大正数；不同 CPU 核心的 TSC 不同步（启用 QPC 时系统已处理，但旧驱动可能失效）。
- 现代 MSVC（2015+）和 libc++/libstdc++ 都已正确封装
QPC，steady_clock::now()就是它 - 若真要手撸，务必检查
QueryPerformanceFrequency(&freq)返回值，且用__emul64或Int128处理 64×64 除法避免截断 - 不要用
GetTickCount64替代——它只有 1–15ms 分辨率，且非单调（可能回绕）
跨平台构建时要注意的 ABI 和编译器差异
steady_clock 的实现细节由标准库决定，不是语言本身保障的。同一份代码在 GCC、Clang、MSVC 下行为一致，但若混用不同标准库（如 Linux 上用 libc++ 编译却链接 libstdc++ 的 .so），时钟对象可能不兼容。
性能影响：所有主流实现都是无锁、寄存器级指令（RDTSC、cntvct_el0 等），调用开销稳定在 20–50 纳秒，远低于任何 syscall。
- 确保 CMake 中
set(CMAKE_CXX_STANDARD 17)或更高，C++11 是底线，但 C++17 起steady_clock必须是单调的 - Android NDK r21+ 默认用 libc++，旧版本可能 fallback 到不稳定的
clock_gettime(CLOCK_MONOTONIC)，需显式指定-DANDROID_STL=c++_shared - 嵌入式平台（如 ARM Cortex-M）若无硬件定时器支持，
steady_clock可能退化为毫秒级 tick，此时得查 BSP 是否提供HAL_GetTick类接口
真正麻烦的从来不是选哪个时钟，而是确保待测代码不被优化、内存访问不被重排、CPU 频率不动态缩放（需要 sudo cpupower frequency-set -g performance）、以及每次测量都清除 cache 和分支预测器状态——这些比时钟本身难控制得多。
