io.Pipe本质是同步通道而非系统管道，因无缓冲、不支持并发读写、需成对goroutine协作；适用单生产者单消费者流式处理，多路场景需MultiReader/MultiWriter等替代方案。
io.Pipe 为什么不是“管道”而是“同步通道”
io.Pipe 返回的 *io.PipeReader 和 *io.PipeWriter 看似像 Unix 管道，但底层没有缓冲、不支持并发读写（除非显式加锁）、也不复用系统 pipe。它本质是带互斥锁的内存通道：写入阻塞直到有 goroutine 在读，读取阻塞直到有 goroutine 在写。这意味着——它只适合单生产者 + 单消费者协作场景，不适合“多写一读”或“一写多读”。
常见错误现象：fatal error: all goroutines are asleep - deadlock。典型触发点是只启动了 writer goroutine，没启动 reader；或者 reader 提前关闭了 *io.PipeReader，writer 再写就 panic。
- 必须成对启动 goroutine：一个专写
pipeWriter，一个专读pipeReader - 不要在 writer 中调用
pipeWriter.Close()后还试图写；reader 收到 EOF 后再读会返回(0, io.EOF) - 若需多消费者，得用
io.MultiReader或手动复制流，不能直接复用同一个*io.PipeReader
生产者消费者流式处理：用 goroutine + io.Pipe 搭骨架
真正实用的流式处理不是靠 io.Pipe 自己扛压，而是用它做“胶水”，把生产逻辑和消费逻辑解耦到不同 goroutine。关键在于谁控制生命周期、谁负责关闭。
使用场景：实时压缩日志、边生成 JSON 边 HTTP 流式响应、大文件分块上传前预处理。
- 生产者 goroutine 负责调用
pipeWriter.Write()，处理完后调用pipeWriter.Close()（这会向 reader 发送 EOF） - 消费者 goroutine 调用
io.Copy(dst, pipeReader)或循环pipeReader.Read()，遇到io.EOF即自然退出 - 不要让 producer 和 consumer 共享同一个
pipeWriter实例去并发写；如需多路数据，先用io.MultiWriter聚合，再写入 pipe
简短示例：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
pr, pw := io.Pipe()
go func() {
defer pw.Close() // 关键：必须 close，否则 reader 永远等 EOF
for _, data := range chunks {
pw.Write(data) // 可能阻塞，等 reader 来读
}
}()
io.Copy(os.Stdout, pr) // reader 侧，自动处理 EOF
替代方案：什么时候该放弃 io.Pipe
当出现以下任一情况，io.Pipe 就成了瓶颈或陷阱：
- 生产速度远高于消费速度，且无法接受背压 ——
io.Pipe无缓冲，会卡死整个流程 - 需要多个 goroutine 并发写入同一目标流 ——
io.PipeWriter不是线程安全的写入口 - 要支持 cancel / timeout ——
io.Pipe本身不实现context.Context，得靠外层 goroutine 控制
此时更稳的选择是：bytes.Buffer（小数据，全量在内存）、sync.Pipe（Go 1.22+ 新增，带缓冲且支持 context）、或直接上 chan []byte 自定义流控。尤其注意 Go 1.22 的 sync.Pipe 接口几乎兼容 io.Pipe，但行为更可控。
容易被忽略的关闭顺序和 error 处理
很多人以为只要 Close() 就万事大吉，其实 io.PipeWriter.Close() 会返回 error，而这个 error 很可能来自 reader 侧提前断开（比如 HTTP 连接被客户端关掉）。不检查它，就等于忽略下游失败。
- producer 中
pw.Close()的返回值必须检查：若为io.ErrClosedPipe，说明 reader 已关；若为其他 error（如net/http.ErrHandlerTimeout），说明消费端异常中断 - reader 侧如果用
io.Copy，它返回的 error 是读过程中的第一个 error，不包含pw.Close()的结果 —— 所以 producer 的 close error 必须单独捕获 - 不要在 defer 里无条件
pw.Close()：如果 producer 因 panic 退出，defer 仍会执行，但此时 reader 可能已不存在，close 会返回io.ErrClosedPipe，掩盖真实问题
复杂点就在这里：pipe 的两端生命周期不对称，error 可能从任意一端发起，且无法跨 goroutine 直接传递。得靠额外 channel 或 sync.Once 控制关闭时机。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
