Go io.Pipe 关闭读取端后写入为什么返回 ErrClosedPipe

读取端调用 Close 后，io.Pipe 的写入端返回 ErrClosedPipe，表示对方已经停止消费，后续字节无法再交付。这是管道关闭契约，不代表数据自动转存到缓冲区，也不应该通过原地重试同一个 PipeWriter 来恢复。

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

为什么读取方退出会影响写入方

io.Pipe 是同步内存管道，PipeReader 与 PipeWriter 共享同一底层管道。它没有用于积压业务数据的内部缓冲区：一次 Write 需要由一次或多次 Read 消费完数据才能完成。如果消费者只读了文件头或若干条记录就返回，生产者可能仍停留在 Write 中。

读取方主动 Close，表达的是“不再接收”。它会让等待中的写入获得关闭结果，新的写入也不能成功。单纯让读取函数返回却不关闭读取端，才可能使写入继续等待；把 Close 删除通常只是掩盖错误，并未解决消费者提前结束的问题。

例如消费者读取四个字节用于识别格式，生产者却写入完整记录。消费者确认不需要剩余数据后，应结束自己的读取端；生产者收到错误后停止当前生产任务。这种配合不要求把管道改造成可恢复的队列。

Close 和 CloseWithError 的错误传给谁

需要先分清调用的是哪一端。读取端的关闭影响写入操作，写入端的关闭影响读取操作。正常写入完成后关闭 PipeWriter，读取方可以用 EOF 表示数据结束；读取端主动关闭时，写入方收到的默认值则是 ErrClosedPipe。

CloseWithError 的返回值与传递的错误不是一回事：关闭方法本身返回 nil，传入的 cause 由另一端后续读写观察。传 nil 也不表示“忽略关闭”：读端传 nil 使用默认关闭错误，写端传 nil 使用 EOF。表格描述单侧关闭的清晰情况；两端都已关闭时，不应承诺还能观察到某个自定义原因。

怎样用最小示例区分默认错误与消费失败原因

下面分别展示提前关闭和带原因关闭。没有消费者并发读取也可以完成，是因为示例在 Write 前已关闭读取端；它不能用来推导正常传输可以一直在同一 goroutine 里先写后读。

package main

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

func main() {
    reader, writer := io.Pipe()
    // 消费者已退出，后续写入无法交付数据。
    _ = reader.Close()
    n, err := writer.Write([]byte("record"))
    fmt.Println(n, errors.Is(err, io.ErrClosedPipe))
    _ = writer.Close()

    reader2, writer2 := io.Pipe()
    cause := errors.New("消费者拒绝记录格式")
    // 自定义原因在写端仍打开时传给 Write。
    _ = reader2.CloseWithError(cause)
    n, err = writer2.Write([]byte("record"))
    fmt.Println(n, errors.Is(err, cause))
    _ = writer2.Close()
}

按官方语义推导，两次写入的 n 都是 0，两次 errors.Is 判断都为 true。这是示例预期，不是本机执行记录。在业务代码中，最好检查可识别的错误值或类型，而不是比较报错字符串。自定义原因也应由当前操作共享同一个错误值，不能每次临时创建相同文字后期待它们相等。

已经读过一部分数据时，n 为什么也要处理

消费者关闭前可能已经接收了当前 Write 的一部分，因此返回错误时，n 不一定为零。它表示这一轮已交付给读端的字节数，并不意味着消费者已经完成业务提交。不要把“Write 没有成功”理解成“对方一个字节也没看见”，也不要把 n 当成数据库事务的确认。

下面让消费者只读取四个字节再关闭。用一个只用于等待收尾的通道接收写入结果，使示例不会在生产 goroutine 完成前直接退出；它没有引入新的取消协议。

type writeResult struct {
    n   int
    err error
}

func readPrefix() (int, error) {
    reader, writer := io.Pipe()
    defer reader.Close()

    done := make(chan writeResult, 1)
    go func() {
        // 8 字节需要消费者继续读取，前缀读取不足以完成这次写入。
        n, err := writer.Write([]byte("HEADbody"))
        _ = writer.Close()
        done 

该片段与上例使用同一个 io 导入。按示例的消费关系，写入方已交付四字节，随后因读取端关闭而结束。要在日志中解释问题，可以同时记录当前任务标识、n 和错误类别；无需把全部原始记录写入日志。

生产者收到 ErrClosedPipe 后应该怎样收尾

先查当前消费者是否本来就允许提前结束。如果它只需要前缀，ErrClosedPipe 可以作为该操作的预期终止结果，在任务层注明提前结束；若消费者原本要求完整数据，它就是需要上报的失败。错误分类依赖调用场景，不能在通用工具函数里一概吞掉。

生产循环应在 Write 返回非 nil 错误时停止继续向同一写端投递，并释放自己持有的文件或其他资源。已关闭的管道不能重新打开；若业务要重做，必须由上层明确创建新的一对端点，并独立考虑此前已交付字节的影响。这里不展开重试和去重协议。

尤其注意提前返回的分支：关闭读端应发生在等待生产者退出之前，否则生产者可能等待读取，消费者又在等待生产者，双方互相等待。defer 可以兜底释放，但如果等待动作在 defer 触发前发生，仍需要显式关闭。

重复关闭和两端同时关闭有什么边界

同一端的 CloseWithError 不会覆盖已保存的关闭原因。因此，先执行普通读端 Close，再试图用 CloseWithError 补充详细原因，不能期待写入方得到后补原因。应在决定退出的分支就传入正确错误，后面的 defer Close 只负责兜底。

如果两端都关闭，写入方也可能只观察到 ErrClosedPipe，不能拿后续 Write 的返回值当作完整故障历史。需要保留消费者原因时，由所属任务记录原始错误，管道错误用于结束另一端当前读写；不要根据两个关闭调用的日志打印顺序断言并发因果关系。

延伸问题

关闭写端后，读端会得到 ErrClosedPipe 吗？仅写端正常关闭且读端仍打开时，读取的结束信号是 EOF。

不再调用 Read，但也不调用 Close，可以吗？生产者可能继续阻塞；提前退出的读取方应负责结束自己的端点。

CloseWithError(nil) 可以让后续 Write 成功吗？不能，读端仍被关闭，只是采用默认关闭错误。

错误说明全部数据都没有交付吗？不能这样判断，应同时看 n，并区分字节交付与业务处理完成。

参考：Go io 管道接口文档、Go 管道关闭与错误传递实现。