Go io.Pipe 写入端提前关闭怎么排查：Reader 读到 EOF 与 CloseWithError 的区别

用 io.Pipe 把生成器接到上传器时，最容易误判的不是并发，而是“写入端已经结束”到底意味着什么。写入端调用 Close()，读取端通常会看到 io.EOF；如果生产者遇到真实错误，应改用 CloseWithError(err)，让读取端拿到这个错误。排查时先处理 n 个有效字节，再判断 err，不要因为读到错误就丢掉同一轮返回的数据。

Close 表示正常结束，CloseWithError 表示异常结束；读取循环应先消费 n>0 的数据，再区分 io.EOF 和具体错误。

问题现场：读取端为什么只看到 EOF

下面的最小例子模拟一个生产者把两段文本写入管道，然后正常关闭写端：

pr, pw := io.Pipe()
go func() {
    _, _ = pw.Write([]byte("part-1\n"))
    _, _ = pw.Write([]byte("part-2\n"))
    _ = pw.Close()
}()

buf := make([]byte, 8)
for {
    n, err := pr.Read(buf)
    if n > 0 {
        fmt.Printf("data=%q\n", buf[:n])
    }
    if err == io.EOF {
        break
    }
    if err != nil {
        return err
    }
}

最后一次读取得到 err == io.EOF，说明写入端正常结束，并不等于前面的数据没有读到。管道把数据交给读取端后，Close 才负责告诉读取端“后面不会再有数据”。

先固定读取循环：n 和 err 不能二选一

io.Reader 允许一次调用同时返回有效数据和非空错误，因此 n > 0 与 err != nil 可以同时成立。对 io.Pipe 的消费代码，最小可靠顺序是：

1. 先检查 n > 0，把 buf[:n] 交给解析或写入逻辑。
2. 再判断 err == io.EOF，把它当作正常结束。
3. 最后处理其他错误，保留原始错误并停止消费。

这段顺序的价值在于：即便生产者关闭前刚写完一小段数据，读取端也不会因为先判断错误而漏掉这段数据。buf 的容量不代表本次数据长度，后续处理必须只使用 buf[:n]。

异常场景：用 CloseWithError 传播真正的失败原因

生产者不能只调用 Close() 来掩盖失败。比如生成第二段内容时发现校验不通过，应把错误传给管道：

var ErrInvalidChunk = errors.New("invalid chunk")

go func() {
    if _, err := pw.Write([]byte("part-1\n")); err != nil {
        return
    }
    _ = pw.CloseWithError(ErrInvalidChunk)
}()

for {
    n, err := pr.Read(buf)
    if n > 0 {
        consume(buf[:n])
    }
    if err != nil {
        if errors.Is(err, ErrInvalidChunk) {
            return fmt.Errorf("pipe producer failed: %w", err)
        }
        if err == io.EOF {
            break
        }
        return err
    }
}

这里读取端可能先拿到 part-1，随后才收到 ErrInvalidChunk。这不是“读到 EOF 后再猜原因”，而是生产者通过 CloseWithError 明确改变了管道的结束状态。

按返回值定位：正常结束、提前关闭还是生产失败

一个实用的现场记录至少要包含：读取循环最后一次的 n、err 文本、生产者写入点和关闭调用。只记录“读到了 EOF”通常不够，因为它无法证明是正常结束还是上游把异常吞掉后调用了 Close()。

常见问题：把 Close 当成错误通知

为什么不建议生产者出错后直接 Close

直接 Close() 只表达结束，不携带失败原因。读取端会按正常 EOF 收尾，日志和重试策略都会失去依据。生产者已有错误对象时，应使用 CloseWithError(err)。

读取到 EOF 时是否一定没有数据

不一定。通用读取契约允许同一次返回里同时有数据和错误，所以仍要先处理 n>0。只有消费完本次数据后，才能把 EOF 作为结束信号。

为什么只关闭读取端会让写入端报错

io.Pipe 需要读写双方配合。读取端不再需要数据时调用 PipeReader.CloseWithError，写入端后续写入可能收到该错误；这属于下游取消路径，不能当成生产者自身失败。

一张清单完成复查

• 正常完成是否由 PipeWriter.Close() 表达。
• 生产失败是否由 PipeWriter.CloseWithError(err) 传递。
• 读取循环是否先处理 n>0，并只消费 buf[:n]。
• 错误日志是否保留了 errors.Is 可识别的原始错误。
• 读取端提前退出时，是否有明确的取消或关闭路径。

把 EOF 看成“正常结束状态”，把 CloseWithError 看成“生产端向读取端提交失败原因”，再按 n 优先的顺序处理返回值，通常就能把这类 io.Pipe 问题从“偶发卡住”缩小到一个具体的读写或关闭点。