io.pipe()返回的io.readcloser一读即eof，是因为写端未写入数据或已关闭；pipe需成对使用，写端必须close()，否则读端阻塞；其无缓存、不可seek，仅适用于一次性流式转发。
io.Pipe() 返回的 io.ReadCloser 为什么一读就 EOF？
因为没写入数据，或者写端提前关闭了。Pipe 是双向配对的：一端写，另一端读；写端不写、或写完没 close()，读端会卡在 Read()；但若写端已 close() 而读端还没读完，后续读就会立刻返回 EOF。
常见错误现象：io.PipeReader.Read() 立即返回 (0, io.EOF)，尤其在测试里直接 new 出 reader 就读——忘了 pipe 必须成对使用。
- 必须用
io.Pipe()一次性拿到io.ReadCloser和io.WriteCloser，不能只取一边 - 写端务必调用
Close()（或让其作用域结束），否则读端永远阻塞 - 不要在 goroutine 外直接读——写操作通常要异步进行，否则会死锁
为什么不能把 io.PipeReader 当作普通 io.Reader 随意复用？
它不是缓冲型 reader，内部无缓存，读取行为直连写端。一旦某次 Read() 返回 n > 0，对应字节就从 pipe 缓冲区移出，不可回退；也没有 Seek() 或 Reset() 方法。
使用场景：适合一次性的流式转发，比如 HTTP handler 中把上游响应体转给下游，或日志采集中把 stderr 捕获后发到远端。
立即学习“go语言免费学习笔记（深入）”；
- 不能反复调用
Read()试图“重读”同一段数据 - 不能传给需要
io.Seeker的库（如某些归档解包器） - 如果需多次读或随机访问，先用
io.ReadAll()拿到[]byte，再包装成bytes.NewReader()
io.Pipe() 在高并发下容易触发 “pipe full” 死锁？
是的。默认 pipe 缓冲区大小为 64KiB（Linux 内核限制，Go runtime 不做额外缓冲）。当写端持续写入、读端处理慢时，写会阻塞在 Write()，直到读端消费掉部分数据；若读端也卡住（比如网络超时、GC 暂停），整个 goroutine 就挂起。
性能影响：不是性能差，而是可靠性差——没有背压反馈机制，写端无法感知下游是否跟得上。
- 避免在无控制的循环中往 pipe 写大量日志或文件内容
- 关键路径上建议加超时控制：用
context.WithTimeout()包裹写操作，并在 goroutine 中 select 处理 - 真要大流量传输，优先考虑
chan []byte+ 显式 buffer 控制，或直接用bytes.Buffer（内存允许前提下）
如何安全地把 io.PipeReader 交给 json.Decoder 或 xml.NewDecoder？
可以，但必须确保写端写的是完整、合法的 JSON/XML 数据，并且写完立刻 Close()。否则 decoder 可能卡住等待更多输入，或解析中途报错（如 invalid character）。
典型错误：写端分多次 Write()，中间没保证结构完整性（例如 JSON 对象未闭合），decoder 就会等下去。
- 写端应尽量一次性写完完整文档，或至少保证每次写都满足语法边界（如每个
Write()写一个完整 JSON object） - 务必在写完后调用
writeCloser.Close()，否则Decode()不会结束 - decoder 本身不处理 EOF 异常，所以要在外层检查
err == io.EOF是否属于预期结束
