不能直接测文件操作需用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_castmicroseconds/microseconds 显式降精度并确保源 duration 支持该转换。推荐写法duration_castmicroseconds(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 下精度差异有多大Linuxglibc kernel ≥ 5.0下 steady_clock 通常能到 ~15 纳秒WindowsQueryPerformanceCounter理论可达 ~100 纳秒但实际受 HAL 和电源策略影响空转时可能跳变。 稿定AI 拥有线稿上色优化、图片重绘、人物姿势检测、涂鸦完善等功能