大文件分片写入不能靠“开更多 goroutine”提速，核心瓶颈是磁盘i/o竞争和缓冲区管理失当；应控制worker数量、隔离文件句柄、显式flush并复用缓冲区。
大文件分片写入不能靠“开更多 goroutine”来提速，核心瓶颈在磁盘 I/O 竞争和缓冲区管理失当；真正有效的并发提升，是控制 worker 数量、隔离文件句柄、显式 Flush 并复用缓冲区。
为什么多个 goroutine 直写同一文件反而更慢
Linux 下 os.File.Write 并发写同一文件时，内核会竞争文件描述符的偏移量锁（尤其是未用 os.O_APPEND 时），导致 syscall 阻塞堆积。实测中 CPU 利用率不足 30%，但吞吐卡在几百 KB/s，strace 可见大量阻塞的 write 调用。
- 即使加
sync.Mutex，也只是把并发退化为串行，没解决系统调用频次高、小 buffer 导致的开销问题 -
bufio.Writer不是 goroutine 安全的，多个 goroutine 共享一个实例会引发数据错位或截断 - 机械盘上并发 >4 个 worker 基本无收益；NVMe SSD 上超过 16 个也易触发调度抖动
正确做法：每个 goroutine 独占文件句柄 + O_APPEND
若目标是追加写入单个大文件（如日志归档），必须让每个 worker 持有独立 *os.File，且以 os.O_WRONLY | os.O_CREATE | os.O_APPEND 打开——内核保证 write 原子性，跳过用户态 Seek 锁争用。
- 避免复用同一个
*os.File，哪怕只读不写，多 goroutine 操作也会错乱读写位置 - 每个 worker 创建自己的
bufio.NewWriterSize(f, 64*1024)，别用默认 4KB 缓冲 - 每次写完必须显式调
wr.Flush()，并检查 error；defer f.Close()不会自动 flush - 写入后立即调
f.Sync()（仅关键场景），否则 crash 后可能丢失最后一批数据
更稳方案：分文件写 + 后期合并
绝大多数场景下，“并发写多个临时文件 → 最后 cat 或 io.Copy 合并”比追加写更可靠、更易调试，且天然规避所有锁问题。
- 按哈希、时间戳或字节偏移命名分片：
output_0001.bin、output_0002.bin - 每个 goroutine 打开专属文件，用
bufio.NewWriterSize(f, 256*1024)写入，完成后fclose - 合并时用
io.Copy流式拼接，不加载全文到内存：dst.WriteAt(chunk, offset)或直接cat part_* > final.bin - 注意：合并前确保所有分片已
Close()，否则 Linux 下cat可能读到空内容
缓冲区与内存泄漏的隐蔽坑
看似简单的 bufio.Reader/Writer 配置，常因缓冲区复用不当或底层切片引用残留，导致内存持续增长、GC 压力飙升。
- 缓冲区大小设为操作系统页大小（4KB）整数倍，如
64*1024，避免O_DIRECT场景下syscall.EINVAL - 用
sync.Pool复用[]byte缓冲，但必须在每次Read后手动buf = buf[:0]清空长度，否则 Pool 无法识别可复用空间 - 千万别把
scanner.Bytes()直接存进 map 或 slice——它返回的是 reader 底层缓冲切片，整块缓冲都会被 GC 持有 - 写入前用
wr.Available()判断剩余空间，避免意外扩容（扩容会 copy 整个底层数组）
真正卡住性能的，往往不是代码逻辑，而是对 os.O_APPEND 的原子性信任不够、对 bufio.Writer.Flush() 的遗漏、或对缓冲区生命周期的误判。这些点不处理，开再多 goroutine 都只是在给调度器添堵。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
