io.Pipe 本质不是“管道”，而是配对的 ReadWriteCloser
很多人一看到 io.Pipe 就默认它像 shell 的 | 那样自动缓冲、背压或支持并发读写 —— 实际上它只是两个绑定的内存端点：一端写，另一端读，**没有内部缓冲区**，也没有 goroutine 自动调度。写端阻塞直到读端开始读，反之亦然。
这意味着你不能只调用 pipeWriter.Write() 就以为数据“发出去了”；如果没人从 pipeReader 调用 Read()，写操作会永远卡住。
- 必须成对使用：
reader和writer来自同一个io.Pipe()调用，不能混用不同管道的端点 - 不支持 Seek / Stat / CloseWrite + CloseRead 独立控制（
Close()关闭的是整个配对） - 错误传播是单向的：写端出错（如
write on closed pipe）会导致读端后续Read()返回该错误
生产者消费者模型里，必须显式启 goroutine 拉取数据
io.Pipe 本身不启动任何 goroutine。如果你把生产逻辑直接塞进主 goroutine 写入 pipeWriter，而没提前启动消费者读取，程序就卡死在第一个 Write()。
典型错误写法：
pipe := io.Pipe()
go func() {
// 生产者：往 pipe 写
pipe.Writer.Write([]byte("hello"))
pipe.Writer.Close()
}()
// 消费者：但这里没读！主 goroutine 直接结束了
正确做法是确保读端先就位，或至少并发启动：
立即学习“go语言免费学习笔记（深入）”；
- 用
go func() { defer pipe.Reader.Close(); io.Copy(dst, pipe.Reader) }()启一个 goroutine 消费 - 生产者也必须在 goroutine 中运行，否则会阻塞主线程
- 注意
pipe.Writer.Close()是通知读端 EOF 的关键动作，漏掉会导致消费者永远等不到结束
别拿 io.Pipe 当 bufio.Scanner 或 json.Decoder 的输入源直接用
io.PipeReader 是 io.Reader，但它的行为和文件、网络流不同：每次 Read() 调用都直通写端，没有预读缓冲。这会让依赖内部缓冲的解析器表现异常。
比如：scanner := bufio.NewScanner(pipeReader) 可能卡在第一次 Scan()，因为 scanner 默认一次读 4096 字节，而写端只写了 5 字节且未关闭 —— 它还在等更多输入，但写端已经停了。
- 如果生产者是逐行/逐帧输出，建议在写入前加
bufio.Writer包裹pipeWriter，并适时Flush() - 若用
json.Decoder解析流式 JSON，确保生产端每次写完一个完整 JSON 值后Flush()，否则 decoder 会阻塞等待下一个 token - 避免在消费者中做耗时同步处理（如 DB 写入），否则会拖慢读端，进而卡住生产端
io.Pipe 没有超时、取消、重试机制，出错就得自己兜底
io.Pipe 的 Read() 和 Write() 都不接受 context.Context，也不返回可取消的 error。一旦某端意外崩溃（比如 panic、提前 return），另一端可能永久阻塞，或收到模糊的 io.ErrClosedPipe。
真实服务中常见陷阱：
- 生产者 goroutine panic 后，
pipeWriter未被关闭 → 消费者Read()一直挂起 - 消费者因超时退出，但没调用
pipeReader.Close()→ 生产者下一次Write()会 panic（“write on closed pipe”） - 没做 recover，goroutine 崩溃导致管道两端泄漏，内存缓慢增长
补救方式很简单：所有使用 io.Pipe 的 goroutine 都应包一层 defer 关闭对应端，并在关键位置加 recover()；更稳妥的做法是改用 chan []byte + sync.Once 手动模拟，或直接上 golang.org/x/sync/errgroup 统一管理生命周期。
