io.pipe适用于单生产者单消费者goroutine的同步场景，如日志生成与http响应解耦；不适用于内存缓存、多读多写或同goroutine读写，因其无缓冲且非并发安全。
io.Pipe 什么时候该用，什么时候不该用
它不是通用的“高性能管道”，而是专为「一个 goroutine 写、一个 goroutine 读」这种单向同步场景设计的。如果你试图在同一个 goroutine 里 Write 后立刻 Read，会死锁——因为 Read 和 Write 都阻塞等待对方就绪。
- 适合：把生成数据的逻辑（比如日志拼接、JSON 流生成）和消费逻辑（比如 HTTP 响应写入、gzip 压缩）解耦到不同 goroutine
- 不适合：替代
bytes.Buffer做内存缓存；也不适合多写者或多读者——io.Pipe的Writer和Reader都不支持并发安全 - 注意：
io.Pipe不带缓冲，写入速度 > 读取速度时，Write会一直阻塞，直到有 reader 拿走数据
PipeReader.CloseWithError 和 PipeWriter.Close 区别在哪
Close 只是通知对方“我写/读完了”，而 CloseWithError 是用来传递错误的唯一方式。如果 writer 在写一半出错（比如序列化失败），必须调用 CloseWithError(err)，否则 reader 的 Read 会一直等下去，或等到 EOF（这容易掩盖真实问题）。
-
PipeWriter.Close()→ reader 下次Read返回io.EOF -
PipeWriter.CloseWithError(err)→ reader 下次Read返回0字节 + 你传的err -
PipeReader.Close()一般不用主动调，除非你想提前终止 writer（writer 再写会返回io.ErrClosedPipe）
为什么 HTTP handler 里直接用 io.Pipe 容易泄漏 goroutine
典型误用：在 http.HandlerFunc 中启一个 goroutine 写 pipe，然后把 reader 交给 http.ServeContent 或直接 io.Copy(w, r)。如果客户端提前断开连接（比如刷新页面），reader 会关闭，但 writer goroutine 还卡在 Write 上，没人收它。
- 必须配合 context 控制生命周期：用
context.WithCancel，在http.Request.Context().Done()触发时，调用writer.CloseWithError - 或者更简单：改用
io.NopCloser+bytes.Buffer，除非数据大到不能全 load 进内存 - 验证泄漏：跑起来后访问接口再中断，看 goroutine 数是否持续增长（
runtime.NumGoroutine()）
PipeReader.Read 返回 0 字节却不报错？这是正常现象
当 writer 已关闭且内部 buffer 为空时，Read 返回 n = 0, err = nil —— 这不是 bug，是 Go 的 io 接口规范行为。很多代码会误判成“数据来了但长度为 0”，结果陷入空循环。
立即学习“go语言免费学习笔记（深入）”；
- 正确判断 EOF：只依赖
err，而不是n == 0 - 典型错误写法：
for { n, _ := r.Read(buf); if n == 0 { break } }→ 会卡住或跳过真实数据 - 正确写法：
for { n, err := r.Read(buf); if err != nil { break }; /* 处理 n 字节 */ } - 注意：
io.PipeReader的Read在 writer 关闭前不会返回n == 0 && err == nil
Pipe 的边界很清晰：它不缓存、不重试、不处理并发、不自动清理 goroutine。用对了省事，用错了问题藏得深——尤其是和 HTTP、context、error 传播混在一起时，漏掉一次 CloseWithError 或少监听一个 Done()，就可能让服务慢慢变慢甚至夯住。
