如何在 Go 中使用 io.Pipe 实现流式数据传输-Golang-PHP中文网

io.pipe仅适合单生产者单消费者、运行在不同goroutine的同步流式协作场景，如日志生成与http响应解耦；不支持seek、重复读、并发读写，且需成对goroutine协作并正确关闭。

如何在 go 中使用 io.pipe 实现流式数据传输

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)

正确做法是：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

用 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 实现流式封装