os.readdir 更适合批量读取文件列表，因其单层读取、不递归、不 stat，返回轻量 fs.direntry；filepath.walkdir 默认递归且逐个 stat，开销大。
为什么 os.ReadDir 比 filepath.WalkDir 更适合批量读取文件列表
当目标是快速获取目录下所有文件路径（不立即处理内容），os.ReadDir 的性能明显优于 filepath.WalkDir。前者只做单层读取、不递归、不 stat 每个条目，返回的是轻量的 fs.DirEntry；后者默认递归且对每个条目调用 stat，开销大。
- 若只需扫描一级目录（如日志归档目录），直接用
os.ReadDir+ 循环过滤后缀，耗时可降低 60%+ - 需要递归？优先用
filepath.WalkDir，但传入自定义fs.DirEntry实现跳过stat—— 只在真正需要文件大小或修改时间时才调用entry.Info() - 注意：Go 1.16+ 才有
os.ReadDir；旧版本只能用ioutil.ReadDir（已弃用）或os.File.Readdir
并发处理文件时，为什么限制 goroutine 数量比“越多越好”更关键
无节制启动 goroutine 处理数百个文件，极易触发系统级瓶颈：文件描述符耗尽、内存暴涨、调度器抖动，反而让整体耗时翻倍。
- 用带缓冲的 channel 控制并发数，例如
sem := make(chan struct{}, 10)，每个 goroutine 执行前sem ，结束后 <code> - IO 密集型任务（如压缩、编码转换）建议并发数设为 CPU 核心数 × 2～4；纯 CPU 计算（如哈希校验）则尽量贴近核心数
- 避免在 goroutine 内直接打开大量文件——
os.Open不释放 fd 会导致too many open files错误，务必用defer f.Close()或显式关闭
io.Copy 和 io.CopyBuffer 在批量复制中的实际差异
批量复制文件时，io.Copy 看似简单，但它内部使用固定 32KB 缓冲区；而大文件（>100MB）或高延迟存储（如 NFS）下，手动指定更大缓冲区能显著减少系统调用次数。
- 普通 SSD 本地复制：默认
io.Copy足够，代码简洁 - 网络文件系统或机械硬盘：改用
io.CopyBuffer(dst, src, make([]byte, 1（1MB 缓冲），实测吞吐提升 20%～35% - 注意：缓冲区不是越大越好，超过 4MB 后收益趋缓，且会增加单次内存分配压力
如何安全地原子替换一批文件而不中断服务
批量更新配置或静态资源时，直接 os.WriteFile 覆盖原文件有风险：写入中途崩溃导致文件损坏、其他进程读到截断内容。必须用原子写法。
- 正确流程：写入临时文件（路径含
.tmp后缀）→os.Chmod设权限 →os.Rename替换原文件（同一文件系统下是原子操作） - 跨文件系统？不能用
Rename，改用os.Symlink：先写新目录（如v2/），再切换符号链接指向，应用通过链接读取 - 别忽略
os.Remove临时文件的错误检查——残留 .tmp 文件可能干扰下次运行
批量场景下，原子性不是锦上添花，而是服务可用性的底线。哪怕只错一个文件，也可能让整个灰度发布失败。
