go中文件写入配合管道本质是用io.pipe构建内存流式中转站，实现读写解耦；关键在阻塞控制、关闭顺序与背压处理，必须成对使用pr/pw并启用goroutine消费，否则写操作永久阻塞。
Go 里文件写入配合管道，本质不是“把文件塞进管道”，而是用 io.Pipe 构建一个内存中的流式中转站，让写文件的动作和上游数据生成解耦——关键在谁控制阻塞、谁负责关闭、谁承担背压。
io.Pipe 的 reader/writer 必须成对使用，不能只写不读
常见错误是调用 pw.Write() 后没启动 goroutine 从 pr 读，导致写操作永久阻塞（哪怕 pw 是带缓冲的）：
-
io.Pipe()返回的pr和pw是绑定的：往pw写多少，pr就能读多少；没读，写就卡住 - 不要在主线程同步写完再读——这等于串行，失去流式意义；必须用
go func() { io.Copy(dst, pr) }()启动消费协程 - 如果下游（比如
os.File）写得慢，pw会自然背压，上游（如解析逻辑）就会被阻塞，这是设计使然，不是 bug
写入大文件时，别用 ioutil.WriteFile + channel 中转
这种写法看似简单，实则破坏流式语义，还浪费内存：
-
ioutil.WriteFile要求整个数据在内存里，和 pipeline 的“边产边消”目标冲突 - 正确路径是：数据源 →
pw→pr→gzip.NewWriter或bufio.NewWriter→os.File - 若中间要加日志或哈希，用
io.TeeReader(pr, hasher)，而不是先读全再分发
关闭顺序错一个，就 panic: send on closed pipe
io.Pipe 的关闭逻辑比普通 channel 更严格：
-
pw.Close()是告诉pr：“不会再有新数据了”，之后pr.Read()会返回io.EOF -
pw.Close()必须在所有写操作完成后调用；如果写 goroutine panic 了，pw没关，pr会永远阻塞在Read() - 绝不能在
pw关闭后还调用pw.Write()，否则直接 panic；也别手动 closepr，它由pw.Close()触发自动关闭 - 安全写法：用
defer pw.Close()包裹整个写逻辑，或在io.Copy完成后显式关
真正难的不是写出能跑的 pipeline，而是当上游突然断流、下游写磁盘卡住、或者中间某个 io.Copy 返回非 nil error 时，你能立刻判断该关哪个 writer、是否要 cancel context、以及下游 reader 还有没有机会 clean exit——这些细节不会报编译错误，但会在高负载时集体爆发。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
