io.pipe仅在单写单读且读端先就位时安全，否则易死锁或立即返回io.eof；它专为异步解耦和接口适配设计，适用于下游只接受io.reader而数据尚在生成的场景。
io.Pipe 不是缓冲区，也不是并发通道，它只在「单写单读」且「读端先就位」时才安全。用错就会死锁或立刻 io.EOF。
为什么 io.Pipe 一 Read 就返回 io.EOF？
根本原因是写端没启动、没写数据，或者提前 Close() 了。PipeReader 和 PipeWriter 是强绑定的：读端调用 Read() 会一直阻塞，直到写端有数据可读；但若写端已关闭（哪怕只写了 0 字节），后续所有 Read() 都立即返回 (0, io.EOF)。
- 常见错误：测试里直接
pr, pw := io.Pipe()后立刻pr.Read()—— 没起 goroutine 写，也没写任何字节 - 别手动 new
*io.PipeReader，必须成对从io.Pipe()获取 - 写端 panic 未
defer pw.Close()，读端将永久阻塞
什么时候必须用 io.Pipe，而不是 bytes.Buffer 或 chan？
只有两种场景值得用：io.Pipe 是为接口契约和异步解耦而生的，不是为了“传数据”本身。
- 下游只接受
io.Reader（比如http.ResponseWriter.Write、gzip.NewReader、json.NewDecoder），但你的数据还在生成中（如日志拼接、流式 JSON 构造） - 写端和读端无法同步启动——例如 HTTP handler 启动后才触发后台任务写入，你不能等全部数据就绪再响应
-
bytes.Buffer会吃光内存，chan []byte不满足io.Reader接口，io.Pipe是唯一能桥接这两者的轻量方案
如何避免 fatal error: all goroutines are asleep - deadlock？
死锁几乎都源于生命周期失控：读没等写、写没等读、或任意一方提前退出。
- 必须用 goroutine 分离读写：同一 goroutine 中
pw.Write()紧跟pr.Read()必死锁 - 读端 goroutine 必须先启动并开始调用
Read()（或io.Copy），再让写端开始Write() - 写端务必
defer pw.Close()，这是通知读端“数据结束”的唯一信号；不关，读端永远卡在Read() - 别在读端 goroutine 外调用
pr.Close()—— 它不是线程安全的，且可能中断正在执行的Read()
io.Pipe 和 os.Pipe 的关键区别在哪？
名字像，用途完全不同：io.Pipe 是纯内存、零系统调用的 Go 接口适配器；os.Pipe 是真正的 Unix 管道，返回 *os.File，用于进程间通信。
-
io.Pipe两端都是 Go 的io.Reader/io.Writer，适合协程间流式解耦 -
os.Pipe返回文件描述符，要配合exec.Cmd使用（如cmd.StdinPipe()），涉及 fd 继承、close-on-exec、syscall 等细节 - 别拿
os.Pipe去替代io.Pipe做协程通信——开销大、难管理、还容易泄露 fd
真正难的不是怎么写，而是判断该不该用。只要你的场景里存在「必须立刻返回 io.Reader，但数据还没生成完」这个矛盾，io.Pipe 才是解药；否则，优先考虑 bytes.Buffer、chan 或直接同步处理。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
