Golang文件批量读写实战教学

本文深入剖析了Go语言中批量文件读写的实战要点，强调使用os.ReadDir替代已弃用的filepath.Walk以实现安全、高效、可控的目录遍历，结合io.Copy构建高可靠批量处理流程；同时重点警示并发控制（避免盲目开goroutine导致文件描述符耗尽）、写入缓冲策略（合理选用bufio.Writer并务必Flush）以及精细化错误处理（区分临时失败与永久错误），直击生产环境中最易被忽视却危害巨大的两大陷阱——fd耗尽和数据静默丢失，为开发者提供可立即落地的高性能、健壮性兼备的文件批量操作方案。

Go 语言本身不提供“批量读写文件”的原子函数，os.ReadDir 和 io.Copy 组合才是实际生产中可靠、可控的批量处理方式。

用 os.ReadDir 安全遍历目录（替代已弃用的 filepath.Walk）

Go 1.16+ 推荐用 os.ReadDir 替代 filepath.Walk，它不递归、不自动跟随 symlink，更可控；若需递归，应手动实现或用 filepath.WalkDir（Go 1.16+）。

• 避免用 filepath.Walk 处理大量小文件——它默认 stat 每个条目，开销大且无法跳过子目录
• os.ReadDir 返回 []fs.DirEntry，调用 entry.Type() 可快速判断是文件还是目录，无需额外 os.Stat
• 注意：os.ReadDir 不保证顺序，如需按名排序，需手动 sort.Slice

示例：

entries, err := os.ReadDir("./input")
if err != nil {
    log.Fatal(err)
}
for _, entry := range entries {
    if !entry.IsDir() && strings.HasSuffix(entry.Name(), ".log") {
        // 处理匹配文件
    }
}

并发读取多个文件时，控制 goroutine 数量别硬开 runtime.NumCPU()

盲目为每个文件启一个 goroutine 容易触发文件描述符耗尽（too many open files）或内存暴涨。真实场景下，并发度应由 I/O 特性决定，而非 CPU 核数。

• 机械盘上高并发读反而降低吞吐；SSD 上通常 4–8 并发较稳
• 用 semaphore（如 golang.org/x/sync/semaphore）或带缓冲的 channel 控制并发数
• 务必对每个 *os.File 调用 Close()，defer 在循环里容易失效，建议显式 close 或用 file.Close() + error check

写入时优先用 bufio.Writer，但别在小文件上过度缓冲

对单个文件写入，bufio.NewWriterSize(f, 64*1024) 可显著减少系统调用；但若每个文件只写几百字节，开 buffer 反而增加分配和拷贝开销。

• 写入总量大（如合并日志）、单文件内容长 → 开 32KB–1MB buffer 合理
• 写入频繁、单次极小（如逐行写指标）→ 直接 f.Write() 更轻量，或用固定小 buffer（4KB）
• 别忘了 w.Flush() —— 没 flush 的 buffer 内容不会落盘，panic 前可能丢失数据

错误处理必须区分临时失败与永久失败（比如 syscall.EAGAIN vs os.ErrNotExist）

批量处理中，某个文件权限不足、被占用、路径不存在很常见。统一 log.Printf("skip %s: %v", name, err) 会掩盖可恢复问题。

• 检查 errors.Is(err, fs.ErrPermission) 或 errors.Is(err, syscall.EACCES) 判断是否权限问题
• 对 syscall.EAGAIN / EWOULDBLOCK（少见但存在），可加简单重试（最多 1–2 次）
• os.IsNotExist(err) 通常该跳过；但若目标目录 output/ 不存在，应提前 os.MkdirAll，而不是让每个写操作都报错

实际项目里，最常被忽略的是：没限制并发数导致 fd 耗尽，以及忘记 flush 导致部分文件看似写入成功实则为空。这两点比语法细节更容易让整个批量任务静默失败。

今天关于《Golang文件批量读写实战教学》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！