不能稳定测到纳秒——其底层依赖平台，Linux 纳秒级但 Windows 实际抖动约 100 ns；需检查 clock::period 验证理论分辨率，并通过多次测量取最小值、避免非确定性操作来提升可靠性。
std::chrono::high_resolution_clock 能否稳定测到纳秒？
不能直接依赖它返回纳秒级真实精度——std::chrono::high_resolution_clock 是类型别名，底层可能映射到 std::chrono::steady_clock 或 std::chrono::system_clock，具体取决于平台。Linux 上通常基于 CLOCK_MONOTONIC，分辨率可达纳秒量级；Windows 上在较新版本（Win10 1809+）用 QueryPerformanceCounter，理论分辨率约 100 ns，但实际抖动常见。关键点：它提供的是「时钟滴答间隔」，不是「测量误差上限」。
实操建议：
- 用
std::chrono::high_resolution_clock::period::num和::den检查实际周期，例如1/1000000000表示 1 纳秒基准（但不保证硬件真能分辨） - 单次测量易受调度、缓存预热、分支预测失败干扰，必须重复多次取最小值或中位数
- 避免在测量块内触发内存分配、系统调用、锁竞争等非确定性操作
怎么写一个可靠的纳秒级计时代码块封装？
手写 RAII 计时器比临时写两行 time_point 更安全，能自动处理构造/析构时的起止时间，并防止忘记 stop。
示例（C++17 起可用）：
立即学习“C++免费学习笔记（深入）”；
struct nanobench {
using clock = std::chrono::high_resolution_clock;
clock::time_point start_;
nanobench() : start_(clock::now()) {}
~nanobench() {
auto end = clock::now();
auto dur = end - start_;
auto ns = std::chrono::duration_cast<std::chrono::nanoseconds>(dur).count();
std::cout << "elapsed: " << ns << " ns\n";
}
};使用方式：
{
nanobench timer;
// 这里放你要测的代码
do_some_work();
}注意点：
- 析构函数输出会引入额外开销，若只想要原始数值，应改用返回
std::chrono::nanoseconds的函数 - 不要在循环内反复创建该对象——构造/析构本身有开销，应把整个循环包进一个 timer 里
- 如需多次测量，建议用
std::vector存储每次duration_cast<nanoseconds></nanoseconds>的结果再统计
为什么用 duration_cast 后数值跳变很大？
这不是转换问题，而是原始 duration 在内部以「时钟周期数」存储，而 nanoseconds 是整数截断转换。例如时钟周期是 15.625 ns（即 1/64 μs），那么 1 个 tick 就是 15.625 ns，duration_cast<nanoseconds></nanoseconds> 会向下取整为 15 ns，2 ticks 变成 31 ns……累积误差明显。
更稳妥的做法：
- 优先用
auto ns = dur.count() * 1e9 / clock::period::den;做浮点换算（保留小数，反映真实周期比例） - 或者直接保留为
clock::duration类型，后续统一用duration_cast到目标单位，避免中间转成nanoseconds再转回 - 若必须整数纳秒且追求一致性，可先用
std::chrono::round<:chrono::nanoseconds>(dur)</:chrono::nanoseconds>替代duration_cast
测量短于 100 ns 的函数有意义吗？
基本没有。现代 CPU 主频 3–5 GHz，一条简单指令（如 add）执行只需不到 1 个周期（≈0.2–0.3 ns），但 high_resolution_clock::now() 本身调用开销就在 20–100 ns 量级（取决于平台和优化等级）。你测出来的“12 ns”，很可能是时钟读取本身的延迟，而非被测函数耗时。
可行方案：
- 对目标函数循环调用 N 次（N ≥ 10000），测总时间后除以 N
- 用
__rdtsc()（x86/x64）获取 CPU 时间戳寄存器值，开销低至 20–30 cycles，但需处理乱序执行、频率缩放、多核 TSC 不同步等问题 - 真正要分析亚纳秒行为，得用 perf、VTune 等硬件性能计数器工具，而不是
std::chrono
最常被忽略的一点：编译器可能把空循环或无副作用计算整个优化掉，务必确保被测逻辑有可观测输出（如写入 volatile 变量、或作为函数返回值参与后续运算），否则测的只是“零”。
