Go os.Pipe怎样把一个进程的输出接到另一个进程为什么结果为空或不符合预期

如果想把一个外部进程的标准输出交给另一个进程处理，os.Pipe 的关键不是“把两个 Cmd 串起来”，而是把同一条管道的写端接到上游的 Stdout，把读端接到下游的 Stdin。结果为空时，优先检查这两个方向是否接反，以及父进程是否还握着没有关闭的写端。

先把 os.Pipe 的数据方向画清楚

os.Pipe 创建的是一条面向文件描述符的单向管道，返回值可以理解为 reader 和 writer。它们不是两个可以随意互换的缓冲区：上游进程的标准输出必须写入 writer，下游进程的标准输入必须读取 reader。

在 Go 的 os/exec 中，Cmd.Stdout 和 Cmd.Stdin 都接受实现了读写接口的对象，而 *os.File 正好可以作为子进程的文件描述符。父进程还会暂时持有这两个对象，所以启动子进程后要明确谁负责关闭它们。

准备一个最小的进程管道项目

为了只观察管道关系，示例让上游的 printf 产生一行文字，下游的 tr 把小写字母转成大写。命令参数使用固定值，示例适用于 macOS 和常见 Linux 环境；Windows 上可以把两个外部命令替换为系统中存在的等价命令，但 os.Pipe 的连接方式不变。

目标结果不是在父进程里先读出上游文本再写给下游，而是让两个子进程直接共享这条管道：上游写入时，下游就可以从标准输入读取。

核心代码：先连接，再按生命周期关闭

下面的代码把启动下游放在前面，再启动上游。两个子进程都启动成功后，父进程立即关闭自己手里的读端和写端；随后分别等待上游和下游结束，并从下游的标准输出缓冲区取结果。

package main

import (
    "bytes"
    "fmt"
    "os"
    "os/exec"
)

func main() {
    reader, writer, err := os.Pipe()
    if err != nil {
        panic(err) // 创建管道失败时没有可继续使用的句柄。
    }
    defer reader.Close() // 启动失败路径也要释放父进程持有的读端。
    defer writer.Close() // 启动失败路径也要释放父进程持有的写端。

    producer := exec.Command("printf", "hello from producer\\n")
    consumer := exec.Command("tr", "a-z", "A-Z")

    producer.Stdout = writer // 上游标准输出只能接管道写端。
    consumer.Stdin = reader   // 下游标准输入只能接管道读端。

    var output bytes.Buffer
    consumer.Stdout = &output // 把下游处理后的结果收回父进程。

    if err := consumer.Start(); err != nil {
        panic(err) // 下游没有启动，继续启动上游也没有意义。
    }
    if err := producer.Start(); err != nil {
        _ = consumer.Process.Kill() // 上游启动失败时，避免下游永久等待输入。
        _ = consumer.Wait()
        panic(err)
    }

    // 两个 Cmd 已经拿到各自的句柄，父进程不再保留副本。
    _ = reader.Close()
    _ = writer.Close()

    if err := producer.Wait(); err != nil {
        panic(err) // 上游退出错误时，先保留真实错误便于定位。
    }
    if err := consumer.Wait(); err != nil {
        panic(err) // 下游错误可能来自命令本身或读取管道失败。
    }

    fmt.Print(output.String()) // 预期看到经过下游处理的大写文本。
}

这里的两个 defer Close 是失败路径兜底，成功启动后显式关闭则是为了尽早释放父进程副本。重复关闭通常只会返回错误，因此示例忽略了显式关闭的返回值；真正需要区分关闭失败的程序可以记录该错误，但不能因为忽略它而把读写方向混淆。

为什么结果为空或等待不返回

先看症状对应的层次，不要一看到空字符串就马上改成更大的缓冲区。

排查时可以按三个问题缩小范围：第一，上游的 Stdout 是否确实指向同一条管道的 writer；第二，下游的 Stdin 是否确实指向同一条管道的 reader；第三，父进程是否在两个 Start 成功后关闭了自己的副本。第三点最容易被忽略，因为即使上游已经退出，只要仍有一个写端打开，下游就可能继续等待更多数据。

从本地小项目扩展到实际集成

当下游输出较大时，不要把“等待上游结束”和“读取下游全部输出”设计成互相阻塞的顺序。可以让父进程并发消费下游输出，或把输出接到文件、另一个专门的读取协程，再等待两个命令。若要传递错误信息，还应分别收集标准输出和标准错误，不要只根据最终的空字符串判断成功。

另外，os.Pipe 只解决当前父子进程之间的文件描述符连接，不负责 shell 的重定向语法，也不会自动解析用户输入。需要多段命令时，应显式创建多条管道并管理每个句柄的所有权；不要把未经处理的字符串拼接成 shell 命令。

验收清单

• 上游 Stdout 连接的是 writer，下游 Stdin 连接的是 reader。
• 两个 Start 的错误都被处理，没有启动失败后继续等待另一端。
• 父进程在子进程拿到句柄后关闭自己的读写端，让 EOF 能够传播。
• 大输出场景没有用单线程的“先 Wait 上游、后读下游”制造管道缓冲区阻塞。
• 外部命令、参数和平台差异已经列入部署说明，空输出不会被误判为 os.Pipe 本身丢数据。

常见问题

为什么只关闭 reader 也会导致下游一直等？

下游判断输入结束依赖所有写端关闭。关闭 reader 只影响读方，父进程如果还保留 writer，EOF 仍然不会到达下游。

os.Pipe 和 io.Pipe 应该怎么选？

要把文件描述符交给外部进程时优先使用 os.Pipe；只在 Go 协程之间传递字节流、无需让子进程继承句柄时，再考虑 io.Pipe。

为什么小字符串可以通过，大文件却卡住？

管道有有限缓冲区。上游写满后会等待读方消费，如果父进程同时同步等待上游结束，就形成互相等待；大数据应并发读取下游输出并分别等待两个进程。