Go io.PipeWriter CloseWithError 怎么把失败传给读端

io.PipeWriter.CloseWithError 的作用不是“返回一个写入错误”，而是把生产者在写端遇到的业务错误，作为读端下一次读取的错误传出去。调用 CloseWithError(err) 后，读端会先消费管道中已经交付的数据；数据读完后，后续 Read 才返回这个 err。如果传入 nil，读端得到的是正常结束的 io.EOF。

官方地址：https://pkg.go.dev/io

这个机制很适合把压缩、转换、分块导出等生产任务接到 io.Copy 或 HTTP 响应流上。关键是：读端必须同时处理“读到了多少字节”和“本次是否带错误”，不能看到数据就忽略错误，也不能把所有非 nil 错误都当成异常重试。

先看清 CloseWithError 的边界

io.Pipe() 创建的是同步内存管道，没有额外缓冲区。写端的 Write 会等待读端消费数据；因此，生产者通常放在 goroutine 中，消费者在主流程中读取。Close() 等价于以 nil 错误关闭：读端最终看到 io.EOF。而 CloseWithError(err) 会把非 nil 错误留给读端。

官方文档还规定，CloseWithError 不会覆盖已经存在的错误，并且自身总是返回 nil。所以它不是用来确认“错误是否被读端处理”的回执；它只是一次性的管道终止信号。

生产者在失败分支关闭写端

下面的例子模拟分块转换：前一块已经写入，后一块处理失败。生产者不应该只从 goroutine 返回错误，因为主流程拿不到这个错误；应使用 CloseWithError 把它挂到管道生命周期上。

package main

import (
    "errors"
    "fmt"
    "io"
)

var errTransform = errors.New("分块转换失败")

func main() {
    reader, writer := io.Pipe()

    go func() {
        // 第一块数据可以正常交付；Write 会等待读端消费。
        if _, err := writer.Write([]byte("part-1\n")); err != nil {
            _ = writer.CloseWithError(err)
            return
        }

        // 这里代表后续转换失败，把原始业务错误交给读端。
        _ = writer.CloseWithError(errTransform)
    }()

    data, err := io.ReadAll(reader)
    fmt.Printf("data=%q\n", data)
    if err != nil {
        // 非 nil 错误表示生产过程失败，不要把它当成正常 EOF。
        fmt.Println("reader error:", err)
    }
}

这个例子中，读端拿到的 data 仍然包含已经成功写入的 part-1，同时 io.ReadAll 返回 errTransform。这正是流式处理需要的语义：部分结果可以保留，但最终状态不能被伪装成成功。

读端要同时检查 n 和 err

如果读端不是 io.ReadAll，而是循环调用 Read，要遵守 io.Reader 的通用约定：一次读取可能既返回了数据，又返回了错误。先处理 n > 0，再根据 err 决定是否结束。

buf := make([]byte, 32)
for {
    n, err := reader.Read(buf)
    if n > 0 {
        // 先消费本次有效字节，最后一块数据不能因 err 非 nil 被丢弃。
        consume(buf[:n])
    }
    if err != nil {
        // EOF 是正常结束；其他错误要回传或记录，不能统一吞掉。
        if !errors.Is(err, io.EOF) {
            return fmt.Errorf("读取生产流失败: %w", err)
        }
        break
    }
}

在具体业务中，最好用 errors.Is 判断可识别的哨兵错误，或用 errors.As 提取带字段的错误类型。不要用错误文本比较来判断是否为某个失败原因。

关闭顺序与常见坑

不要让写端提前 Close。如果生产者在还有数据要传时调用 Close()，读端会在数据耗尽后得到 EOF，无法知道生产过程是否中途放弃。

不要把 CloseWithError 的返回值当作业务结果。它按文档总是返回 nil；真正的错误要由读端读取到。写端若在 Write 时发现读端已关闭，应该把这个写错误记录下来，而不是再次向同一个 writer 发送新的业务错误。

不要忽略同步特性。io.Pipe 没有缓冲，写端和读端需要有明确的并发配对。生产者启动后，主流程应持续读取；在超时场景可以由外层协调取消生产任务，并保证所有退出路径最终关闭写端。

可以按下面的检查清单收尾：

• 正常完成使用 Close 或 CloseWithError(nil)。
• 业务失败使用原始错误调用 CloseWithError。
• 读循环先处理 n，再区分 io.EOF 与其他错误。
• 记录并处理 Write 的返回值，避免 goroutine 静默退出。

常见问题

CloseWithError 会立即让读端丢掉已写数据吗？不会。已经交付到管道的数据仍需被读端消费；错误通常在数据读完后暴露。

为什么传入 nil 后不是业务错误？因为 nil 表示正常关闭，读端按 Reader 约定返回 io.EOF。只有非 nil 的错误才表示生产过程失败。