io.Pipe本质是共享64KiB环形缓冲区的非线程安全读写对，仅支持单reader单writer并发模式，多goroutine读写会竞态；正确用法是writer goroutine负责Close/CloseWithError，reader通过Read返回值感知EOF或错误。
io.Pipe 本质是啥，为什么不能随便并发读写
io.Pipe 返回一对 *io.PipeReader 和 *io.PipeWriter，底层共享一个带缓冲的环形队列（固定 64KiB），但**它不是线程安全的读写对**。很多人以为“Pipe 是管道，天然支持并发”，结果一上 go func() { r.Read(...) }() 就 panic 或死锁——因为 Read 和 Write 方法内部没有加锁，多个 goroutine 同时调用会竞态访问内部状态。
常见错误现象：fatal error: concurrent map read and map write（内部用 map 做等待队列）、read/write on closed pipe、读到空数据或卡住。
- 只允许一个 goroutine 调用
Read，另一个（或多个）goroutine 调用Write—— 这是官方文档明确要求的使用模式 - 如果真要多 reader，得自己套一层
sync.Mutex或改用chan []byte+io.ReaderFrom模拟 -
io.Pipe不适合做“广播”或“扇出”，更适合单生产者 → 单消费者的数据接力
正确用法：启动 writer goroutine 后，主线程或另一 goroutine 调用 Read
典型场景：把 HTTP 请求体、日志行、序列化结构体等“边生成边传输”，避免全量加载进内存。比如处理一个大 JSON 数组流：
pr, pw := io.Pipe()
go func() {
defer pw.Close() // 必须 close，否则 Read 会一直阻塞
enc := json.NewEncoder(pw)
for _, item := range items {
if err := enc.Encode(item); err != nil {
pw.CloseWithError(err) // 传错误给 reader
return
}
}
}()
// 此处 pr 可传给 http.ResponseWriter.Write、json.NewDecoder(pr) 等
dec := json.NewDecoder(pr)
for {
var v MyStruct
if err := dec.Decode(&v); err == io.EOF {
break
} else if err != nil {
log.Println(err)
break
}
// 处理 v
}
-
pw.Close()和pw.CloseWithError(err)是 reader 退出循环的关键信号，漏掉就会死锁 - writer 中一旦出错，必须调
CloseWithError，否则 reader 的Read会永远等下去 - 不要在 writer 里直接调
pr.Close()—— reader 侧关闭是非法操作，会 panic
和 bytes.Buffer / chan 对比：什么时候该选 Pipe
不是所有“内存流转”都该用 io.Pipe。它真正的价值在于「让两个本不耦合的 io 接口能接起来」，比如把一个只接受 io.Reader 的函数（如 http.Post）和一个只产生字节流的逻辑连起来。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
bytes.Buffer：适合小数据、需随机访问或多次读取的场景；无 goroutine 安全问题，但数据全驻内存 -
chan []byte：可控性强，可多 reader / multi writer，但需要自己处理粘包、EOF、关闭协调 -
io.Pipe：当你必须塞进io.Reader或io.Writer接口，且生产/消费节奏异步、不想缓存全部数据时才用 - 性能影响：Pipe 内部有 mutex 和条件变量，比
bytes.Buffer略重；但比手写 channel 协调逻辑更轻量、更符合 io 接口契约
容易被忽略的 Close 时机和 error 传播细节
很多人以为 pw.Close() 就万事大吉，其实 io.Pipe 的错误传播是单向且延迟的。reader 只有在下一次 Read 时才会看到 writer 侧的 error，而且这个 error 只出现一次。
- writer 中调
pw.CloseWithError(fmt.Errorf("boom"))后，reader 下次Read返回0, boom，再之后的Read全返回0, io.EOF - 如果 writer panic 了但没显式
CloseWithError，reader 会卡在Read上，直到超时或上下文取消 - 务必用
defer pw.Close()包裹整个 writer 函数，但要在所有Write完成后才触发 —— 放太前会导致 reader 提前 EOF - 别依赖
pr.Close()来中断 reader：它不会通知 writer，writer 还可能继续往已关闭的 pipe 写，触发 panic
真正难的从来不是怎么启动 goroutine，而是谁负责关、什么时候关、关错了会卡在哪——Pipe 的接口简单，但关闭契约很脆。
