os.chtimes/chmod批量调用慢，因每次均触发独立utimensat系统调用，需重复路径解析、权限校验、inode查找，无批量接口；路径深、数量大时，dentry cache低效导致cpu/内存密集，开销线性甚至超线性增长。
直接用 os.Chtimes 或 os.Chmod 逐个调用修改大批量文件元数据，性能瓶颈不在磁盘写入本身，而在系统调用开销和内核路径解析——尤其当文件路径深、数量过万时，耗时会线性甚至超线性增长。
为什么 os.Chtimes/Chmod 批量调用慢得明显
每个 os.Chtimes 都触发一次 utimensat(2) 系统调用，每次都要：解析完整路径、验证权限、查找 inode、更新时间戳字段。没有批量接口，无法合并操作。
- 路径越长、层级越深，
stat类路径解析开销越大；Linux 下每层目录都要查 dentry cache，命中率低时直接变内存+CPU 密集型任务 - 即使所有文件在同一目录，
os.Chtimes仍需对每个文件做独立openat(AT_FDCWD, path, ...)+utimensat，无法复用 fd - Go runtime 对小系统调用的封装（如
syscall.Syscall6）有固定开销，万级调用下不可忽略
用 os.File 复用 fd 提升单目录元数据更新速度
若待修改文件都在同一目录下，可先 os.Open 目录本身，再用 unix.UtimesNanoAt（Linux/macOS）或 syscall.WindowsSetFileTime（Windows）配合相对路径批量操作——跳过路径解析，直击 inode。
- Linux/macOS：用
golang.org/x/sys/unix的UtimesNanoAt(dirfd, relPath, ts)，dirfd来自os.Open("/path/to/dir")，relPath是文件名（不含路径） - Windows：需用
syscall.CreateFile打开文件句柄后调用SetFileTime，但无法跨文件复用句柄；不如 Linux 场景收益大 - 注意：该方式要求所有目标文件必须是目录下的直接子项，不支持嵌套子目录
避免隐式 stat 和遍历开销：别用 filepath.WalkDir 做元数据批量更新
如果你只是想改一批已知路径的文件时间戳，却用 filepath.WalkDir 再过滤，等于白跑一遍 stat ——它默认对每个 DirEntry 调用 entry.Info() 获取完整元数据，而你根本不需要读取大小或 mode。
- 正确做法：提前准备好文件路径列表（比如从
os.ReadDir获取fs.DirEntry后只取.Name()），跳过Info()调用 -
os.ReadDir返回轻量DirEntry，不触发stat；filepath.WalkDir默认触发，除非你传入自定义fs.DirEntry并在ReadDir实现里跳过Stat - 如果必须递归获取路径，用
filepath.WalkDir但显式避免entry.Info()：仅当entry.Type().IsRegular()为 true 时才处理，且绝不调用entry.Info()
并发控制不是越多越好，尤其对元数据操作
元数据更新本质是轻量系统调用，但并发过高会引发内核锁竞争（如 ext4 的 inode lock）、调度抖动，反而降低吞吐。实测在 SSD 上，并发 8～16 goroutine 基本达到峰值，再高无收益甚至倒退。
- 用带缓冲的 channel 控制并发数，例如
sem := make(chan struct{}, 16)，每个 goroutine 执行前sem ，结束后 <code> - 不要为每个文件启一个 goroutine；把路径切片分块（如每块 100 个路径），每 goroutine 处理一块，减少 goroutine 创建/销毁开销
- 错误处理要收敛：单个文件
os.Chtimes失败不影响其余，记录日志即可，别 panic 或中断整个流程
真正卡住性能的，往往不是“怎么改”，而是“怎么拿到要改的路径”和“怎么避免重复解析”。绕过路径解析、跳过无关 stat、控制并发粒度，这三点比选哪个函数更重要。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
