os.OpenFile 并发写同一文件易出错，因系统限制及 *os.File 非线程安全；应避免多 goroutine 共享句柄写入，改用 WriteAt（区域不重叠）、临时文件合并，或令牌限流（如 sem := make(chan struct{}, 10)）。
为什么 os.OpenFile 在并发下容易出错
直接在 goroutine 里反复调用 os.OpenFile 打开同一个文件进行写入，大概率触发 permission denied 或 text file busy 错误——尤其在 Windows 上。根本原因不是 Go 并发模型有问题，而是底层系统对同一文件的并发写入控制严格，且 *os.File 本身不是线程安全的写缓冲区管理器。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 避免多个 goroutine 同时对一个文件句柄调用
Write、WriteAt或Truncate - 若必须并发写入不同偏移，改用
file.WriteAt(data, offset)，但需确保各 goroutine 写入区域完全不重叠 - 更稳妥的方式是让每个 goroutine 写入独立临时文件，最后由主 goroutine 合并
用 sync.WaitGroup + chan 控制并发写入节奏
常见误区是起几百个 goroutine 拼命往磁盘塞数据，结果 I/O 队列拥塞、系统缓存颠簸，整体耗时反而比串行还长。关键不是“能不能并发”，而是“并发多少才不拖慢”。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用带缓冲的
chan struct{}做并发令牌（例如sem := make(chan struct{}, 10)），每次写入前sem ，写完后 - 配合
sync.WaitGroup等待所有写任务结束，不要依赖 sleep 或轮询 - 对小文件（
io.Copy 和 bufio.Writer 对性能影响巨大
逐字节或小块写入（比如循环调用 f.Write([]byte{b})）会引发大量系统调用，是并发文件操作中最常见的性能杀手。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先使用
io.Copy(dst, src)处理流式数据（如从 HTTP body 直接拷贝到文件），它内部自动使用 32KB 缓冲 - 手动写入时，务必包装
*os.File为*bufio.Writer，并设置合理BufferSize（如bufio.NewWriterSize(f, 1） - 别忘了在关闭前调用
wr.Flush()，否则最后一块缓冲数据可能丢失
临时文件 + 原子重命名才是安全落地的关键
直接覆盖原文件（os.Rename(temp, original)）看似简单，但在 Linux 上它本质是原子的，而 Windows 需要额外处理：如果目标已存在，os.Rename 会失败。很多人卡在这一步，却误以为是并发问题。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 始终生成唯一临时路径：
tempFile, err := os.CreateTemp("", "proc-*.tmp") - 写完后先
tempFile.Close()，再调用os.Rename(tempFile.Name(), targetPath) - Windows 下若
Rename报invalid argument，需先os.Remove(targetPath)（注意权限和进程占用） - 合并多路输出时，用
os.OpenFile(..., os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)追加，而非每次覆盖
真正难的从来不是启动 goroutine，而是判断哪部分该并发、哪部分该串行、缓冲设多大、临时文件怎么清理——这些细节不靠试错，得看 strace / perf 数据，或者至少跑一次 go tool trace。
