根本原因是写端未写入数据或已关闭；PipeReader与PipeWriter强绑定，写端一旦Close()（哪怕未写任何字节），后续Read()均立即返回(0, io.EOF)。
io.Pipe 一读就返回 io.EOF，根本原因是什么
不是管道坏了，而是写端没写、或提前关闭了。PipeReader 和 PipeWriter 是强绑定的：只要 PipeWriter 被 Close()（哪怕一个字节都没写），后续所有 Read() 都会立刻返回 (0, io.EOF)。
常见错误现象：
- 测试代码里
pr, pw := io.Pipe()后直接pr.Read()—— 没起 goroutine 写，也没调pw.Write() - 写端 panic 退出，没执行
defer pw.Close()，读端永远卡住 - 误用
new(io.PipeReader)单独构造 reader ——io.Pipe()必须成对获取，否则无后端支撑
为什么同一 goroutine 里 Write 后 Read 必死锁
io.Pipe 是同步阻塞管道，没有缓冲区中转。Write 必须等到另一个 goroutine 正在 Read 才能返回；反过来，Read 也必须等到有数据可读或写端关闭才返回。两者挤在一个 goroutine 里，就是“你等我、我等你”。
正确做法只有一条：读写必须分离到不同 goroutine，且读端要先就位。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 启动读端 goroutine（例如用
io.Copy(dst, pr)或循环pr.Read()），再触发写端 - 写端务必用
defer pw.Close()，这是通知读端“数据结束”的唯一信号 - 别在读端 goroutine 外调
pr.Close()—— 它非线程安全，可能中断正在执行的Read()
什么时候该用 io.Pipe，而不是 bytes.Buffer 或 chan
io.Pipe 不是通用数据容器，它只解决两个具体问题：
- 下游要求
io.Reader接口（比如http.ResponseWriter、gzip.NewReader、json.NewDecoder），但你的数据还在生成中（如流式 JSON、日志拼接） - 写端和读端无法同步启动（例如 HTTP handler 已返回响应头，后台 goroutine 才开始导出数据库并写入）
其他情况请绕道：
- 想缓存数据？用
bytes.Buffer——io.Pipe不带缓冲，写快读慢就卡死 - 需要多生产者或多消费者？用
chan []byte或带缓冲的chan——io.Pipe只支持单写单读 - 跨进程通信？用
os.Pipe+exec.Cmd——io.Pipe是纯内存、零系统调用的协程间适配器
写端 panic 时如何避免读端永久阻塞
panic 会跳过 defer pw.Close()，导致读端 forever 等在 Read() 上。关键不是“防 panic”，而是确保错误能被读端感知。
必须显式处理异常路径：
- 写端逻辑包在
func() { defer pw.Close() ... }()里，但 panic 前要补上pw.CloseWithError(err) - 例如序列化失败：
if err := json.NewEncoder(pw).Encode(data); err != nil { pw.CloseWithError(err); return } - 读端收到的不再是
io.EOF，而是你传的具体 error，能区分“正常结束”和“出错中断”
最易忽略的一点：HTTP handler 中用 io.Pipe 时，客户端断连会关闭 ResponseWriter，但写端 goroutine 仍存活 —— 必须用 req.Context().Done() 关联 cancel，否则 goroutine 泄漏肉眼可见。
