Go os.Pipe 读端提前关闭后写端为什么会得到 broken pipe

先说结论：os.Pipe 返回的是一对相互连接的 *os.File：读端 r 负责接收，写端 w 负责发送。读端一旦提前 Close()，写端再继续 Write 就失去了可接收的对端，Unix-like 环境中常见的结果就是 broken pipe。它通常说明对端已经结束或被关闭，不等于写入端的业务数据本身损坏。

官方文档：https://pkg.go.dev/os#Pipe

我第一次遇到这个错误时，直觉是给写循环加重试。但真正需要先回答的问题是：读端为什么关闭、写端是否还应该继续发数据、这次错误是否只是子进程正常结束的信号。把这三个问题分开，处理方式会清楚很多。

先确认 os.Pipe 的两端关系

os.Pipe() 返回 r 和 w。写入 w 的字节由读取 r 的一端消费；它不是两个彼此独立的文件，也不是一个可以无限缓存数据的消息队列。任何一端被关闭，另一端的后续 I/O 都需要重新判断。

package main

import (
    "fmt"
    "os"
)

func main() {
    // r 和 w 是同一条管道的两个端点，不能把它们当成普通独立文件使用。
    r, w, err := os.Pipe()
    if err != nil {
        panic(err)
    }
    defer r.Close()
    defer w.Close()

    // 写入 w 的内容应由持有 r 的读取方消费。
    n, err := w.Write([]byte("message\n"))
    fmt.Printf("written=%d err=%v\n", n, err)
}

这里的关键不是 Write 调用看起来像文件写入，而是它背后仍然依赖另一个端点保持可用。读端没有消费者时，写入还可能因为管道缓冲暂时成功；这不代表读端永远存在。

读端提前关闭后，故障现场是什么样

典型场景是：读取方只要了前几行数据，随后主动退出；发送方却仍在循环中写剩余内容。读端的 Close 让它不再参与 I/O，写端下一次或后续某一次 Write 就可能收到对端已断开的反馈。

package main

import (
    "fmt"
    "os"
)

func main() {
    // 这个示例只展示生命周期关系，不依赖某个平台的具体错误文本。
    r, w, err := os.Pipe()
    if err != nil {
        panic(err)
    }

    // 读端提前结束，后续写入已经没有接收方。
    _ = r.Close()
    defer w.Close()

    n, writeErr := w.Write([]byte("仍在发送的数据"))
    // n 可能小于输入长度；只看错误字符串会漏掉部分写入信息。
    fmt.Printf("written=%d err=%v\n", n, writeErr)
}

在 Unix-like 系统上，底层通常会以 broken pipe 语义告诉写端“没有读端了”；具体错误可能被 Go 包装成带路径和操作名的错误，平台不同也可能出现不同文本。判断时应优先保留 err 和 n，不要只用字符串相等比较。

先看关闭时机，再看 Write 返回值

这个问题最容易被误判为“某一行数据写坏了”。实际上，os.File.Write 的返回值同时告诉你写入了多少字节以及遇到的错误。n 时，不能把这次写入当成完整成功；即使 n 暂时等于长度，也只说明这一刻写入完成，不说明下一次仍有对端。

可以把日志记录在写入边界，至少保留批次、写入长度和错误链。下面的分类函数不把所有错误都归为 broken pipe，而是为后续的策略判断留出位置。

package main

import (
    "errors"
    "fmt"
    "os"
    "syscall"
)

func writeChunk(w *os.File, data []byte) error {
    // n 和 err 必须一起判断，部分写入不能被当成完整发送。
    n, err := w.Write(data)
    if err == nil && n == len(data) {
        return nil
    }

    // Unix-like 系统通常把对端关闭表现为 EPIPE；其他平台应保留原始错误。
    if errors.Is(err, syscall.EPIPE) {
        return fmt.Errorf("pipe peer closed after %d/%d bytes: %w", n, len(data), err)
    }
    if err != nil {
        return fmt.Errorf("pipe write failed after %d/%d bytes: %w", n, len(data), err)
    }

    // 没有错误但写入不完整同样不能视为成功。
    return fmt.Errorf("short pipe write: %d/%d bytes", n, len(data))
}

这里的 syscall.EPIPE 适合 Unix-like 环境的分类分支；如果代码需要跨平台运行，不要把这个分支当成唯一判断，更不要为了匹配错误文本而丢掉原始错误。

把错误放回子进程通信的时间线

在父进程向本地工具或子进程发送标准输入时，broken pipe 往往意味着接收方已经退出、提前关闭标准输入，或者因为输入不符合预期而停止读取。发送方仍然继续推送数据，于是错误在写端出现。

此时先问“子进程为什么退出”比立刻重试更重要。若它已经按业务条件正常完成，写端收到对端关闭是生命周期结果；若它因为输入错误退出，则应该读取退出状态和诊断输出，修正发送内容，而不是反复写同一批数据。

package main

import (
    "errors"
    "fmt"
    "os"
    "syscall"
)

func handlePipeWrite(err error) error {
    // 对端关闭属于可分类事件，但不能直接吞掉所有写入错误。
    if errors.Is(err, syscall.EPIPE) {
        return fmt.Errorf("接收方已结束，停止继续发送: %w", err)
    }
    if errors.Is(err, os.ErrClosed) {
        return fmt.Errorf("当前写端已关闭: %w", err)
    }
    return fmt.Errorf("管道写入失败，需要继续调查: %w", err)
}

实际接入 exec.Cmd 时，还要把子进程的退出状态、标准错误和管道写入错误放在同一个请求或任务上下文里记录。单独看到一条 broken pipe，无法证明业务失败；它只说明写入发生时，对端已经不再接受数据。

修复动作是统一关闭责任，而不是无条件重试

我通常会把管道的所有权写进函数边界：谁创建端点，谁负责关闭；谁决定“数据发送完成”，谁负责停止写循环；读取方一旦结束，要有信号让写入方尽快退出。这样可以避免一个 goroutine 关闭读端，另一个 goroutine 还在无期限发送。

package main

import (
    "errors"
    "fmt"
    "os"
    "syscall"
)

func sendRecords(w *os.File, records [][]byte) error {
    for _, record := range records {
        // 每轮都检查错误，避免对端结束后继续消耗剩余输入。
        n, err := w.Write(record)
        if err == nil && n == len(record) {
            continue
        }
        if errors.Is(err, syscall.EPIPE) {
            // 对端已经关闭，停止重试并把事件交给上层分类。
            return fmt.Errorf("receiver closed pipe after %d/%d bytes: %w", n, len(record), err)
        }
        if err != nil {
            return fmt.Errorf("send record failed after %d/%d bytes: %w", n, len(record), err)
        }
        return fmt.Errorf("short write: %d/%d bytes", n, len(record))
    }
    return nil
}

如果业务允许接收方提前结束，就把这类错误转成明确的状态，例如“对端已完成”“对端拒绝继续接收”或“子进程异常退出”。如果业务要求全部数据必须送达，则应把它升级为任务失败，并带上退出状态与最后一批数据的标识。

几个容易混淆的边界

最后记住这三个判断

第一，os.Pipe 的读端提前关闭后，写端继续写自然可能得到 broken pipe；第二，判断不能只看错误文本，还要结合 n、关闭时机和对端退出状态；第三，修复重点是明确生命周期和关闭责任，只有在协议允许且能证明对端仍可用时才考虑重试。

如果只是想让两个 goroutine 在内存中传递数据，不要因为本文标题就把 os.Pipe 和 io.Pipe 混为一谈：本文只讨论操作系统管道文件描述符这一条边界。选对抽象，错误分类才不会从一开始就偏离。

相关问题

读端关闭后写端一定立刻报错吗？不一定，错误可能在后续某次写入出现，具体还受缓冲和平台实现影响；写端不能因此假设对端仍然可用。

broken pipe 能不能直接忽略？只有在业务已经确认对端正常完成、剩余数据不再需要发送时，才可以把它归类为可接受结束；否则应保留上下文并调查。

为什么要同时记录 n 和 err？因为写入可能只完成了一部分，单看错误或单看字节数都会丢失传输是否完整的信息。

跨平台代码该怎么判断？保留错误链并使用平台适配的分类逻辑；不要把 Unix 的 syscall.EPIPE 或某个错误字符串当成所有系统的唯一契约。