goroutine并发读写文件需避免闭包捕获循环变量、禁止复用*os.file、追加写必须用os.o_append、控制并发数防too many open files。
goroutine 并发读多个不同文件：别让闭包捕获循环变量
直接在 for 循环里启动 goroutine 但不传参，会导致所有 goroutine 实际读的是最后一个文件路径——这是最常踩的坑。
- 错误写法：
for _, path := range files { go func() { os.ReadFile(path) }() }——path是循环变量，被所有 goroutine 共享 - 正确写法：显式传参，
go func(p string) { os.ReadFile(p) }(path)，或在循环体内声明局部副本path := path -
os.ReadFile内部已封装Open→ReadAll→Close，无需手动管理句柄，适合中小文件 - 大文件慎用
os.ReadFile，改用os.Open+bufio.Scanner或分块io.ReadAt避免内存暴涨
并发写多个不同文件：每个 goroutine 必须独占 *os.File
写入不同目标文件时，只要路径不重叠，就完全不需要锁——但必须确保每个 goroutine 自己打开、自己关闭。
- 禁止复用同一个
*os.File句柄：多个 goroutine 调用其Write会因共享offset和内核缓冲状态引发竞态 - 推荐模式：
f, _ := os.OpenFile(outPath, os.O_CREATE|os.O_WRONLY|os.O_TRUNC, 0644)→ 写入 →defer f.Close() - Windows 下路径必须用
filepath.Join("dir", "file.txt")，硬写"dir\file.txt"在非 Windows 环境会失败 - 小文件高频写入时，给每个 goroutine 配一个
bufio.Writer（注意：不能复用！）能显著减少系统调用
并发写同一个文件：os.O_APPEND 是唯一安全的追加方案
想让多个 goroutine 往同一日志文件末尾写内容？别自己加 sync.Mutex 包裹 f.Write，那只能防住构造内容的竞态，防不住 write(2) 调用本身的交错。
- 唯一内核级保障原子追加的方式：打开文件时必须带
os.O_APPEND标志，例如os.OpenFile("log.txt", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644) - 此时每次
f.Write前，内核自动lseek到当前文件末尾，再写入，全程原子 - 若需覆盖写或随机写（如更新二进制 offset），必须由单个 writer goroutine 统一接收
struct{ offset int64; data []byte }请求并顺序执行 - 注意：即使用了
os.O_APPEND，内容拼接逻辑（比如格式化字符串）仍需sync.Mutex保护，否则可能写入乱序文本
控制并发数：不设限等于制造 too many open files
几百个文件就启几百个 goroutine？大概率触发 too many open files 错误，尤其在默认 ulimit=1024 的 Linux 系统上。
- 用带缓冲 channel 当信号量：
sem := make(chan struct{}, 10)，每个 goroutine 启动前sem ，结束后 <code> - 避免无缓冲 channel 收集大量结果：
make(chan Result, len(files))比make(chan Result)更安全，防止 goroutine 卡死 - 大文件 + 高并发组合下，I/O 吞吐反而下降（机械盘/NFS 尤其明显），实测 5–20 并发常是性能拐点
- 临时文件、未关闭句柄、panic 后未 recover 的 goroutine 都可能导致资源泄漏——每个 goroutine 内务必
defer f.Close()
真正难的不是启动 goroutine，而是让每个 goroutine 对文件句柄生命周期、偏移管理、系统资源边界有明确意识。多数崩溃都发生在“以为安全”的地方：比如复用 bufio.Scanner、提前关闭父级文件、或在 defer 里关错的 file。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
