最可靠方案是 std::chrono::high_resolution_clock，取两次时间点相减并用 duration_cast 转换为纳秒等单位；避免 system_clock（受 NTP 影响）和 clock()（Windows 精度仅 15ms）；需排除编译器优化、CPU 频率调节、缓存未预热等干扰。
用 std::chrono 高精度计时最可靠
Windows 下的 clock() 和旧式 time() 精度低、易受系统负载干扰，Linux 下还可能返回错误值；std::chrono 是 C++11 起标准库提供的跨平台高精度方案，推荐无脑用它。
核心思路：取两次时间点，转成统一单位后相减。常用组合是 std::chrono::high_resolution_clock（实际通常映射到系统最高精度时钟）：
#include <chrono> auto start = std::chrono::high_resolution_clock::now(); // 你的代码 auto end = std::chrono::high_resolution_clock::now(); auto duration = std::chrono::duration_cast<std::chrono::nanoseconds>(end - start).count();
-
nanoseconds、microseconds、milliseconds按需选，别直接用count()不加转换——返回的是“时钟滴答数”，不是毫秒 - 避免用
std::chrono::system_clock测执行时间，它反映的是挂钟时间，可能因 NTP 校时跳变 - 单次测量意义不大，尤其短代码；建议循环多次取平均，或用
std::chrono::steady_clock（更强调单调性）
clock() 在什么情况下还能凑合用
仅适用于粗略评估 CPU 时间占比，比如调试算法复杂度趋势，且只在 Linux + GCC 或 Windows + MSVC 的简单控制台程序里勉强可用。
- 返回的是进程累计 CPU 时间（单位是
CLOCKS_PER_SEC），对多线程不敏感，也不含系统调用等待耗时 - Windows 下
clock()实际精度只有 ~15ms，测不到微秒级差异 - 必须除以
CLOCKS_PER_SEC才得秒数，常见漏写导致结果大出 100 万倍 - 示例：
double ms = (clock() - start) * 1000.0 / CLOCKS_PER_SEC;
Windows 专用但更准的 QueryPerformanceCounter
当需要比 std::chrono 更底层控制，或兼容极老 C++ 编译器（如 VC6）时才考虑。它绕过 C++ 标准库，直读硬件计数器，精度可达纳秒级。
Windows-Android_SSH_Remote_Control
下载
通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。
立即学习“C++免费学习笔记（深入）”；
- 必须配对使用
QueryPerformanceFrequency换算，否则数值无意义 - 不能跨不同 CPU 核心调用（现代 Windows 已基本解决，但仍建议绑定线程亲和性）
- 示例关键段：
LARGE_INTEGER freq, start, end; QueryPerformanceFrequency(&freq); QueryPerformanceCounter(&start); ... QueryPerformanceCounter(&end); double ms = (end.QuadPart - start.QuadPart) * 1000.0 / freq.QuadPart; - 纯 Windows API，Linux/macOS 完全不可用
容易被忽略的性能干扰项
再准的计时函数，测出来也是“包含干扰的总耗时”。真正想看算法本身开销，这些点不处理，数据就白跑了：
- 编译器优化（如
-O2下空循环可能被整个删掉）：测之前加volatile或把结果强制输出（如std::cout << result） - CPU 频率动态调节（Intel SpeedStep / AMD Cool'n'Quiet）：运行前固定 P-state，或多次运行取最小值而非平均值
- 缓存预热缺失：首次运行常慢一截，建议先跑一次“热身”，再正式计时
- 系统后台任务抢占：关闭杀毒软件、浏览器等，Windows 可设进程优先级为
HIGH_PRIORITY_CLASS
精度只是起点，排除干扰才是让计时数据可信的关键。
