Go IOPipe 写端提前关闭后读端如何处理

我第一次用 io.Pipe 把生产者和消费方接起来时，遇到过一个很像“正常结束”的故障：生产者中途返回了错误，读端却只拿到 io.EOF。问题不在 Read 丢了错误，而是写端用普通 Close 关闭了管道。对这个场景，结论很直接：正常结束调用 Close，提前失败调用 CloseWithError(err)，读端再同时处理已经读到的字节数和错误。

官方文档入口：https://pkg.go.dev/io。下面的图是配合章节理解的原创静态说明图，不是运行截图或执行证据。

普通 Close 为什么会把故障变成 EOF

io.Pipe 是同步的内存管道：写入需要和读出配合，写端并不负责缓存一大块数据。PipeReader.Read 会等待数据到来，或者等待写端关闭。写端调用普通 Close 时，标准库把这件事解释为“不会再有更多数据”，所以读端的结束信号是 io.EOF。

如果生产者实际上是因为压缩失败、上游读取失败或业务校验失败而提前退出，那么 EOF 只说明“数据流结束”，不能说明“数据完整”。这正是我排查时最容易误判的地方：读循环看见 EOF 就返回 nil，真正的上游错误已经被吞掉了。

生产者提前失败时，把原始错误交给读端

我现在会把生产者的收尾动作集中在一个位置：成功完成时关闭写端，失败时用 CloseWithError。这样消费者不需要猜测“EOF 是正常结束还是上游半途退出”，只需要根据返回的错误做自己的决策。

package main

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

var errSource = errors.New("上游读取失败")

func consume(r *io.PipeReader) error {
	buf := make([]byte, 4)
	for {
		n, err := r.Read(buf)
		if n > 0 {
			// 先处理本次已经交付的数据，不能因 err 非 nil 丢掉它。
			fmt.Printf("收到 %q\\n", buf[:n])
		}
		if err != nil {
			// EOF 代表正常结束；其他错误要保留给调用方。
			if errors.Is(err, io.EOF) {
				return nil
			}
			return fmt.Errorf("消费管道：%w", err)
		}
	}
}

func produce(w *io.PipeWriter) {
	defer func() {
		// 真实代码应由成功/失败分支决定关闭原因，避免 defer 覆盖业务错误。
		_ = w
	}()
	if _, err := w.Write([]byte("part")); err != nil {
		_ = w.CloseWithError(err)
		return
	}
	_ = w.CloseWithError(errSource) // 模拟生产者提前失败，把原因传给读端。
}

示例把生产者和消费者的核心边界放在一起看：消费者先检查 n，再检查 err；生产者只有在确实发生异常时才传入非 nil 错误。标准库文档说明，CloseWithError 不会覆盖已经记录的前一个错误，并且自身返回 nil，因此业务错误要在调用前保存好。

读端不要只写成“err 不为空就丢数据”

很多消费循环写成 n, err := r.Read(buf); if err != nil { return err }。这段代码的问题不是每次都错，而是它假定“有错误就没有数据”。按照 io.Reader 的约定，一次读取可以先交付最后一段数据，再同时返回结束或失败信号，所以更稳妥的顺序是先处理 buf[:n]，再判断错误。

这条规则也解释了为什么图里把“有效数据区”和“结束原因”画成两个边界。n 描述本次已经交给读端的字节，err 描述下一步是否还能继续；二者不是互斥字段。若消费者把数据交给解码器，还要确认解码器能区分完整消息、半条消息和上游错误。

关闭顺序和 ErrClosedPipe 怎么判断

写端提前失败时，责任通常是生产者调用 CloseWithError，读端在收到错误后结束消费。反过来，如果读端因为请求取消、下游不再需要数据而先关闭，后续写端会得到 io.ErrClosedPipe；这表示消费者撤销了管道，不应再当成上游数据格式错误。

我会把几种情况分开记录：

不要在两端都无条件调用带不同错误的关闭方法，期待后一个错误覆盖前一个错误；CloseWithError 不会覆盖已有错误。也不要用字符串比较判断所有失败，优先用 errors.Is 检查 io.EOF 或 io.ErrClosedPipe，业务错误则继续用 %w 保留链路。

写入这类代码前，我会核对这四点

• 能区分“数据自然结束”和“生产者带错误结束”，成功分支不伪装成失败，失败分支不调用普通 Close。
• 读循环先处理 n > 0，再决定 EOF、重试还是返回错误。
• 读端主动关闭后，生产者停止写入，不把 io.ErrClosedPipe 误报成上游故障。
• 多个 goroutine 只由明确的一方负责最终关闭，避免生命周期责任互相覆盖。

对我来说，io.Pipe 最有价值的地方不是“少写一个缓冲队列”，而是让生产者和消费者之间的背压与错误通道都显式存在。只要把关闭原因和数据长度分开处理，写端提前退出就不会再静默变成一次看似正常的 EOF。

常见问题

写端调用 CloseWithError(nil) 会怎样？ 它等价于正常关闭，读端后续通常得到 io.EOF。只有传入非 nil 错误时，读端才会看到该错误。

读端收到业务错误后还要继续 Read 吗？ 通常不应继续把同一个管道当成可恢复数据源；先释放下游资源，再根据错误是否可重试决定是否重新建立一条管道。

为什么写端 Write 也可能返回错误？ 因为读端可以提前关闭。此时写入方需要停止生产并检查 io.ErrClosedPipe，不能继续阻塞等待读端。