Go io.Pipe.CloseWithError 如何把写端失败传给读端：EOF、错误值与关闭顺序

导出服务把 CSV 逐行写给压缩器时，写端可能在读端还没消费完之前发现校验失败。这个场景里，单纯调用 Close() 只能让读端看到 io.EOF，真正的失败原因会丢掉；io.PipeWriter.CloseWithError 才能把原因沿着管道交给读端。

把 io.Pipe 当成同步交接点：先由 Write 交付数据，失败时由写端 CloseWithError 结束，读端在下一次 Read 中区分具体错误和正常 io.EOF。

io.Pipe 解决的是哪一段交接

io.Pipe() 返回 PipeReader 和 PipeWriter。它没有内部缓冲队列把数据无限堆起来：一次 Write 会等到一个或多个 Read 消费完对应数据。因此它适合把“生产字节”的代码接到“消费字节”的代码，而不适合拿来当任意大小的缓存。

写端正常结束时调用 Close()，读端在剩余数据读完后得到 io.EOF。如果写端遇到上游校验错误，就要把错误放进 CloseWithError，否则消费方只能误以为导出完整结束。

最小实验：写入、读取和错误关闭

下面的例子让写端先交付一段数据，再以 errExport 结束。读端循环先处理 n > 0 的数据，再判断错误，这样即使最后一次读取同时带回数据和错误，也不会漏掉已收到的字节。

package main

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

var errExport = errors.New("export validation failed")

func main() {
    reader, writer := io.Pipe()
    go func() {
        _, _ = writer.Write([]byte("row-1\\n"))
        _ = writer.CloseWithError(errExport)
    }()

    buf := make([]byte, 8)
    for {
        n, err := reader.Read(buf)
        if n > 0 {
            fmt.Printf("data=%q\\n", buf[:n])
        }
        if err != nil {
            fmt.Printf("read error=%v\\n", err)
            break
        }
    }
}

这个程序的关键路径是 Write 交付 row-1，然后 CloseWithError 设置 errExport；读端处理完数据后，下一次 Read 得到这个错误。这里不要只看 err 就跳出循环，否则可能把同一次读取里的有效字节丢掉。

Close、CloseWithError 和读端关闭怎么区分

writer.Close() 等价于以空错误关闭写端，读端最终得到 io.EOF。writer.CloseWithError(errExport) 则保留具体错误，读端可以用 errors.Is 或直接比较哨兵错误来决定是否重试、记录失败或删除半成品。

反过来，如果读端已经不再需要数据，应调用 reader.Close()。此时后续写入会返回 io.ErrClosedPipe；写端的 goroutine 必须检查 Write 的返回错误，不能继续假设消费者存在。

关闭顺序也有一个容易误判的点：CloseWithError 不会覆盖已经记录的关闭错误，而且方法本身始终返回 nil。所以不能把它的返回值当成“下游是否收到业务错误”的确认；真正的结果要由读端的 Read 观察。

错误传播的验收方式

接入压缩器、哈希计算器或文件落盘器时，建议把读端的结果分成三类：读到字节就继续消费；遇到 io.EOF 才表示正常结束；遇到 errExport 或其他非 EOF 错误就丢弃不完整产物并记录原因。

• 正常结束：写端完成所有 Write 后调用 Close()，读端收完数据并看到 io.EOF。
• 生产失败：写端调用 CloseWithError(errExport)，读端收完已交付数据后看到 errExport。
• 消费提前退出：读端关闭后，写端的 Write 返回 io.ErrClosedPipe，生产协程应及时返回。

别把同步管道当成性能优化开关

io.Pipe 的价值是边生产边消费和明确的错误传播，不是自动提升吞吐。生产端和消费端速度差距较大时，Write 的阻塞正是背压；如果业务需要吸收突发流量，应另行设计有界队列，并明确内存上限。

实际验收可以记录三件事：正常结束是否稳定得到 io.EOF，失败路径是否得到 errExport，读端提前退出后生产协程是否能从 io.ErrClosedPipe 返回。不要用“CloseWithError 返回 nil”替代这三项检查。

相关问题

CloseWithError(nil) 和 Close 有区别吗？

对写端的正常结束语义基本一致，读端最终得到 io.EOF。需要传递失败原因时才使用非 nil 错误。

为什么读端还会先读到数据再读到错误？

已经由 Write 交付的数据仍应被消费；关闭错误描述的是后续结束状态，不会自动撤销已读字节。

CloseWithError 的返回值能确认错误传播成功吗？

不能。官方文档规定该方法始终返回 nil，且不会覆盖已有关闭错误；应在读端检查 Read 返回的错误。

把结束状态交给真正的消费者判断

在 io.Pipe 上，Write 负责交付，Close 表示正常 EOF，CloseWithError 表示带原因的失败，Read 才是消费方看到最终状态的位置。只要保留“先处理 n > 0，再判断 err”这个顺序，流式导出、压缩和转发代码就不容易把半成品误判成成功。