Go exec.Cmd.StdinPipe 怎样向子进程写入输入并正确关闭

我在把一段输入交给外部命令时，最容易踩到的坑不是命令参数，而是输入管道的结束时机：数据已经写完，子进程却还在等下一段内容。用 exec.Cmd.StdinPipe 时，核心顺序是 Start、写入、Close 写端、Wait。最后的 Close 很重要，它通常就是子进程读到 EOF、开始收尾的信号。

官方地址：https://pkg.go.dev/os/exec#Cmd.StdinPipe

把 StdinPipe 当成一条有明确所有权的资源：Go 侧负责写入和关闭写端，子进程负责读取 stdin，Wait 负责等待命令完成。不要在 Wait 之后才关闭，也不要让多个 goroutine 无序地写同一个管道。

先把 StdinPipe 放回 Cmd 的资源关系中

StdinPipe 返回一个 io.WriteCloser。它是 Go 进程持有的写端，另一端会接到子进程的标准输入。调用它不会启动命令，也不会自动把字节写进去；命令仍然要由 Start 或 Run 驱动。

我会先把输入来源和命令生命周期分开看：输入来源可以是字符串、文件或编码器，Cmd 只负责把这份字节接到子进程；写入端关闭之后，子进程才有机会结束“继续读取”的循环。这里没有必要把它理解成一个隐含的缓冲队列。

按 Start、Write、Close、Wait 传完一份输入

最小而稳妥的写法是先拿到管道，再启动命令，写完全部输入后关闭写端，最后等待命令退出。下面的命令只用于演示 stdin 关系，代码块中的中文注释说明了每个资源边界；它不是本机执行截图或运行结果。

package main

import (
    "errors"
    "fmt"
    "io"
    "os/exec"
)

func feedCommand(input string) error {
    // 用 cat 读取标准输入，重点展示输入管道的生命周期，不代表必须使用 shell。
    cmd := exec.Command("cat")

    // StdinPipe 返回 Go 侧的写端，调用本身不会启动子进程。
    stdin, err := cmd.StdinPipe()
    if err != nil {
        return fmt.Errorf("创建 stdin 管道失败: %w", err)
    }

    // 先启动命令，再向已经连接的标准输入写数据。
    if err := cmd.Start(); err != nil {
        _ = stdin.Close() // 启动失败时释放 Go 侧仍持有的写端。
        return fmt.Errorf("启动命令失败: %w", err)
    }

    _, writeErr := io.WriteString(stdin, input)
    // 写完后关闭写端，让子进程能够收到 EOF 并结束读取。
    closeErr := stdin.Close()
    // Wait 负责回收子进程；它不能替代前面的 Close。
    waitErr := cmd.Wait()

    switch {
    case writeErr != nil:
        return fmt.Errorf("写入 stdin 失败: %w", writeErr)
    case closeErr != nil:
        return fmt.Errorf("关闭 stdin 失败: %w", closeErr)
    case waitErr != nil:
        return fmt.Errorf("命令退出失败: %w", waitErr)
    default:
        return nil
    }
}

func main() {
    // 真实业务中可把这里替换为文件或编码器，但仍要保留关闭写端的动作。
    if err := feedCommand("第一行\n第二行\n"); err != nil {
        if errors.Is(err, exec.ErrNotFound) {
            fmt.Println("找不到命令，请先检查 PATH")
        }
        fmt.Println(err)
    }
}

这段代码把错误先保存，再按“写入、关闭、退出”的顺序处理。即使 Wait 最后返回了错误，也不应该覆盖一个更早发生的写入失败；否则调用方只会看到“命令失败”，却不知道输入没有完整送达。

输入量变大后，瓶颈会从 API 变成背压

短字符串通常可以直接写入；当输入来自大文件、压缩流或持续生成的数据时，写入可能因为子进程读取较慢而阻塞。这不是 StdinPipe 失效，而是管道在提供背压：写端速度不能无限超过读端速度。

我会把输入生产和命令等待放到同一个生命周期里管理。需要异步生产时，单独的写入 goroutine 只拥有写端，并在写完后关闭；主 goroutine 负责接收写入错误并调用 Wait。不要让多个 goroutine 同时写同一个 io.WriteCloser，除非业务自己提供了明确的串行化。

如果输入来自文件，优先让文件读取错误尽早返回，并确保命令不会因为写端一直不关闭而永久等待。若业务需要超时，应该把取消策略和输入关闭策略一起设计；单纯把更多数据塞进管道不能解决子进程不读的问题。

把四类错误分开，排查会快很多

有一个容易忽略的边界：如果代码已经用 cmd.Run()，就不应再手动安排一套互相冲突的启动和等待流程；而使用 StdinPipe 进行主动写入时，Start、写入、关闭、Wait 的所有权要保持清晰。官方文档也特别强调，读取或写入管道时要遵守命令生命周期，避免在 Wait 后继续操作已被关闭的管道。

相关问题

只调用 Write 不调用 Close 会怎样？

子进程可能继续等待更多输入，尤其是按 EOF 判断结束的程序。写完后关闭写端是把输入生命周期交给子进程收尾的关键动作。

Close 后还能继续 Write 吗？

不应继续写。关闭代表 Go 侧不再提供输入，后续写入应视为生命周期错误，而不是正常追加。

大输入一定要开 goroutine 吗？

不一定。小输入可以同步写；持续或大体量输入才需要考虑异步生产、错误传递和取消时的资源回收，重点是让写端只有一个清晰的拥有者。