不能直接测文件操作，需用duration_cast将time_point差值转为微秒整数；避免system_clock（受时间调整影响）和盲目依赖high_resolution_clock（实际可能等价于steady_clock或system_clock）；推荐steady_clock并检查其精度。
std::chrono::high_resolution_clock 能不能直接测文件操作？
不能直接用，但可以——关键是它返回的是时钟点（time_point），不是秒数。你得自己做减法再转成微秒，而且必须用 duration_cast，不然默认输出可能是纳秒或系统内部滴答数，看着像 0 或溢出。
- 别用
system_clock：它可能被系统时间调整干扰，文件操作耗时测量不准 - 别用
steady_clock的“绝对值”：它只保证单调，不保证分辨率够高；某些旧 Linux 内核下它的精度只有毫秒级 -
high_resolution_clock是别名，实际可能等价于前两者之一，所以最好显式用steady_clock+ 检查period::num / period::den
怎么把 time_point 差值转成准确的微秒整数？
直接 count() 不行，因为 duration 类型默认是纳秒或更小单位，直接强转会截断或溢出。必须用 duration_cast<microseconds></microseconds> 显式降精度，并确保源 duration 支持该转换。
- 推荐写法：
duration_cast<microseconds>(end - start).count()</microseconds> - 别写
(end - start).count() / 1000：如果底层是纳秒，除法可能丢精度；如果是皮秒，结果直接是 0 - 如果文件操作极快（count() 可能为 0 —— 这不是 bug，是精度限制，不是代码写错了
open()/read()/close() 这类系统调用怎么包进计时？
不能只包函数调用本身，要包整个语义操作。比如 open() 成功后才开始计时读，失败就别计了；read() 多次调用需累计，不能只计最后一次。
- 错误示范：
auto t1 = steady_clock::now(); read(fd, buf, size); auto t2 = ...;—— 忽略了read()返回值检查，失败时耗时无意义 - 正确思路：计时块以「操作成功完成」为边界，例如
if (n = read(fd, buf, size)) { /* 计时结束 */ } - 注意
close()可能阻塞（尤其 NFS 或满 buffer 的 ext4），它也得单独计时，别和write()合并在一个区间里
Windows 和 Linux 下精度差异有多大？
Linux（glibc + kernel ≥ 5.0）下 steady_clock 通常能到 ~15 纳秒；Windows（QueryPerformanceCounter）理论可达 ~100 纳秒，但实际受 HAL 和电源策略影响，空转时可能跳变。
立即学习“C++免费学习笔记（深入）”；
- 别信文档写的“high resolution”——实测用
steady_clock::period::num和::den打印出来看才是真的 - 在 VM 里跑？精度大概率掉到毫秒级，
count()值会整千整万地跳，这时候微秒计时没意义 - 如果要跨平台稳定输出，建议最低按微秒四舍五入（
round(duration_cast<microseconds>(d).count())</microseconds>），避免显示 0.3 微秒这种误导值
真正难的不是写对那三行计时代码，而是判断哪段 IO 行为值得测、哪次结果该丢弃——比如第一次 open() 触发 page cache 加载，耗时天然偏高，直接当性能 baseline 就会误判。
