Go io.Pipe 写端关闭后读端为何收到 EOF

我在把一个生产者接到消费者时，第一次看到 io.Pipe 的读端返回 io.EOF，很容易把它当成异常。其实，只要写端已经把数据写完并正常调用 Close()，读端把剩余数据读完后收到 EOF 就是正常结束信号；只有需要把业务失败传给读端时，才应该使用 CloseWithError(err)。

判断原则很简单：写端正常收尾对应 io.EOF，写端带错误收尾对应那个业务错误，读端主动关闭则通常意味着消费者不再接收。不要只看 Read 的错误字符串，要结合关闭入口判断。

io.Pipe 的读写关系决定了 EOF 的含义

io.Pipe() 返回一对同步连接：PipeWriter.Write 写入的数据由 PipeReader.Read 读取，中间没有一个可以随意积压数据的独立缓冲区。写入可能等待读端接收，读端也可能等待写端提供数据，所以它更像一个直接连接的传输边界，而不是文件或网络连接的替身。

当写端调用 Close() 时，Pipe 会把“后面不会再有数据”告诉读端。读端如果还有已经写入但尚未取走的数据，会先得到这些数据；数据读尽后，下一次读取才会得到 io.EOF。因此 EOF 表示正常结束，不代表最后一批数据丢失。

Close、CloseWithError 和读端关闭不是一回事

正常生产完成时使用 PipeWriter.Close()。如果生产过程中发生了需要让消费者知道的错误，例如上游解码失败，可以调用 PipeWriter.CloseWithError(err)；读端后续读取会看到这个错误，而不是把失败伪装成 EOF。传入 nil 时，语义回到正常关闭。

PipeReader.Close() 表示消费者提前放弃。此时写端继续写入可能得到 io.ErrClosedPipe，生产者应停止继续生成数据，否则 goroutine 可能因为没人读取而一直等待。三种关闭入口的选择，可以按“谁结束、结束是否正常、另一端是否还要继续工作”来判断。

用读取循环把 EOF 和真实错误分开

下面的示例只展示关闭语义，不依赖本地文件或网络。生产者成功写完后正常关闭；如果写入失败，则通过 CloseWithError 传播。消费者必须先处理本次读取拿到的字节，再判断错误，因为一次 Read 可能同时返回 n>0 和结束错误。

package main

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

func readPipe() error {
    pr, pw := io.Pipe()

    go func() {
        // 写入完成后用 Close 表示正常结束，读端最终会看到 io.EOF。
        if _, err := io.WriteString(pw, "第一段\n第二段\n"); err != nil {
            // 写端失败时把真实错误交给读端，避免被误判为正常 EOF。
            _ = pw.CloseWithError(err)
            return
        }
        // 只有确认没有错误时才走正常关闭路径。
        _ = pw.Close()
    }()

    var got bytes.Buffer
    buf := make([]byte, 8)
    for {
        n, err := pr.Read(buf)
        if n > 0 {
            // 先保存本次已经读到的数据，再处理同一次 Read 的错误。
            _, _ = got.Write(buf[:n])
        }
        if err != nil {
            if errors.Is(err, io.EOF) {
                // EOF 是写端正常收尾后的结束信号，不当成失败。
                fmt.Print(got.String())
                return nil
            }
            // 其他错误表示生产端或关闭路径确实失败。
            return fmt.Errorf("read pipe: %w", err)
        }
    }
}

这里没有把 io.EOF 直接打印成“错误”，也没有在看到错误后丢弃 n>0 的数据。若生产者需要传递业务错误，消费者的 errors.Is 判断应针对那个具体错误类型，而不是只判断字符串是否包含 “pipe”。

实际选择时最容易踩的三个边界

• 不要在成功写完前关闭。关闭会宣布后续没有数据；如果还有内容要写，应继续使用当前写端，或让新的 Pipe 承担下一段独立数据。
• 不要把 EOF 当成数据损坏。EOF 只说明当前输入已经结束，是否完整要由协议自身的长度、校验和或记录规则判断。
• 消费者放弃后要让生产者退出。读端提前关闭时，生产者的下一次写入可能失败；生产者应检查错误并结束 goroutine，不能继续无条件写。

相关问题

为什么读端不是立刻收到 EOF？因为已经写入但尚未读取的数据仍要先交付，EOF 只会出现在数据耗尽之后。

io.Pipe 适合替代所有缓冲队列吗？不适合。它强调同步传递和背压；如果需要独立积压、限长队列或多消费者，应选择明确提供这些语义的组件。

官方事实可参考 https://pkg.go.dev/io#Pipe。记住关闭入口和错误语义，遇到 EOF 时就能判断它是正常收尾，还是需要继续追查的真实失败。