io.Pipe仅适合单生产者单消费者、运行在不同goroutine的同步流式协作场景，如日志生成与HTTP响应解耦；不支持seek、重复读、并发读写，且需成对goroutine协作并正确关闭。
io.Pipe 适合什么场景
它只适合单生产者 + 单消费者、且两者运行在不同 goroutine 的简单流式协作。不是通用管道，不能 seek、不能重复读、不支持并发写或并发读——io.Pipe 返回的 *PipeReader 和 *PipeWriter 都是非线程安全的，一旦多 goroutine 同时调用 Read 或 Write，行为未定义。
典型适用场景：把一个生成数据的函数（比如压缩、加密、日志行生成）和一个消费数据的函数（比如 HTTP 响应写入、文件保存、解析器）解耦，中间不落地、不缓存全量。
基础用法：别忘了启动 goroutine 写入
io.Pipe 创建后，Read 会阻塞直到有数据可读；Write 会阻塞直到有 reader 在读——如果 writer 不在 goroutine 里跑，程序直接卡死。
常见错误是这样写：
pr, pw := io.Pipe()
pw.Write([]byte("hello")) // ❌ 死锁：没人读，Write 永远阻塞
io.Copy(os.Stdout, pr)
正确做法是：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 用
go func() { ... pw.Close() }()启动写入逻辑 - 确保写完后调用
pw.Close()，否则pr.Read会一直等下去 - 如果写入过程可能出错，用
pw.CloseWithError(err)通知 reader
如何安全地处理写入失败
写入端 panic 或提前返回，但没调用 Close，reader 就永远 hang 在 Read 上。更糟的是，如果 writer goroutine 崩溃了，pr 还在等，整个流程就不可恢复。
推荐模式：
- 把写逻辑包进匿名函数，用
defer pw.Close()或defer pw.CloseWithError(err) - 捕获关键错误（如 JSON 编码失败、网络读取中断），立即
pw.CloseWithError(err) - reader 侧检查
io.EOF（正常结束）和其它 error（如 writer 主动报错）
示例片段：
pr, pw := io.Pipe()
go func() {
defer pw.Close()
enc := json.NewEncoder(pw)
for _, v := range data {
if err := enc.Encode(v); err != nil {
pw.CloseWithError(err) // ← 关键：让 reader 知道出错了
return
}
}
}()
io.Copy(os.Stdout, pr) // 这里会收到 writer 报的 error
替代方案比 pipe 更健壮的时机
当遇到这些情况，该换方案了：
- 需要多个 reader 消费同一份流 → 改用
io.MultiReader+ 缓存，或用chan []byte自建广播机制 - 写入端不确定何时结束，但 reader 要做超时控制 → 用
bytes.Buffer或sync.Pool配合io.ReadCloser实现可取消读取 - 要复用连接或支持重试 →
io.Pipe生命周期太短，更适合用net.Conn或自定义io.Reader实现流式封装
真正容易被忽略的点：pipe 的内部缓冲区大小固定为 16KB，写入超过这个量就会阻塞 writer，直到 reader 消费掉一部分——这既是背压机制，也是性能瓶颈点。如果 reader 处理慢，writer 就卡住，整个流水线停摆。
