Go Cmd 输出管道忘记关闭时怎么避免子进程卡住

用 Go 的 os/exec 启动外部命令时，程序卡在 ReadAll 或 Wait，不一定是少写了一行 Close。对 StdoutPipe 和 StderrPipe，更重要的规则是：Start 后持续读取输出，确认读取结束后再调用 Cmd.Wait。如果只是一次性收集结果，直接把输出接到 bytes.Buffer 并调用 Run，通常更简单。

只收集输出时，优先去掉手工管道

StdoutPipe 返回的是连接到子进程标准输出的 io.ReadCloser，它适合需要边运行边解析的场景。若目标只是拿到完整文本，手工管理这个 reader 反而增加了一个容易误判的生命周期。可以让 Cmd 直接写入 buffer：

cmd := exec.Command("go", "env", "GOMOD")
var stdout, stderr bytes.Buffer
cmd.Stdout = &stdout // 直接接收标准输出，避免额外的 pipe reader
cmd.Stderr = &stderr // 单独保留错误输出，便于定位失败原因

if err := cmd.Run(); err != nil { // Run 会等待进程并回收 Cmd 资源
    return fmt.Errorf("读取 go env 失败: %w，stderr=%s", err, stderr.String())
}
result := strings.TrimSpace(stdout.String())

这种写法的边界也很清楚：输出量很大时，内存 buffer 会随输出增长；需要流式解析、实时显示或限制输出大小时，才值得使用 pipe 或自定义 writer。Cmd.Wait 会释放关联资源，并且对由 StdoutPipe 创建的管道通常会负责关闭，因此不要把“必须手动 Close”当成通用结论。

需要实时读取时，先把两个管道消费完

同时读取 stdout 和 stderr 时，两个管道都可能被写满。如果只读取其中一路，子进程可能因为另一条管道没有消费者而阻塞。下面的结构让两个 reader 并行读完，然后再等待命令退出：

cmd := exec.CommandContext(ctx, "sh", "-c", "printf 'ok\\n'; printf 'warn\\n' >&2")
stdout, err := cmd.StdoutPipe()
if err != nil {
    return err // 创建标准输出管道失败，不应继续 Start
}
stderr, err := cmd.StderrPipe()
if err != nil {
    return err // 两条管道必须同时准备好
}
if err := cmd.Start(); err != nil {
    return fmt.Errorf("启动命令失败: %w", err)
}

var out, errOut []byte
var readErr, readErr2 error
var wg sync.WaitGroup
wg.Add(2)
go func() {
    defer wg.Done()
    out, readErr = io.ReadAll(stdout) // 持续消费 stdout，避免写端堵塞
}()
go func() {
    defer wg.Done()
    errOut, readErr2 = io.ReadAll(stderr) // stderr 也必须有独立消费者
}()
wg.Wait() // 先确保两个读取任务已经结束
if readErr != nil || readErr2 != nil {
    return fmt.Errorf("读取命令输出失败: stdout=%v stderr=%v", readErr, readErr2)
}
if err := cmd.Wait(); err != nil { // 读取完成后再 Wait，统一取得退出结果
    var exitErr *exec.ExitError
    if errors.As(err, &exitErr) {
        return fmt.Errorf("命令退出失败: %w，stderr=%s", err, errOut)
    }
    return err
}
fmt.Printf("stdout=%s stderr=%s", out, errOut)

这里没有在读取 goroutine 中提前关闭 pipe。官方文档说明，Wait 会在看到命令退出后关闭这类管道；真正不能违反的是读取尚未完成就调用 Wait。若上下文取消，CommandContext 会触发命令取消，仍要检查 io.ReadAll 和 Wait 各自返回的错误。

EOF 一直不返回时，先查谁还持有写端

如果子进程已经看似完成，但 io.ReadAll 迟迟没有 EOF，常见原因是命令又启动了子进程，而后者继承了 stdout 或 stderr 的写端。只要仍有一个写端打开，读取器就不能判断输出已经结束。使用 sh -c、脚本包装器、后台任务或长驻进程时尤其容易遇到。

排查时可以先去掉 shell 包装，直接执行真实程序；再把实时 pipe 改成文件或 buffer 做对照。如果改后不再卡住，问题多半在继承的文件描述符，而不是某个 Close 调用的位置。

把取消、读取和退出错误分开处理

生产代码里不要只写一个“失败”日志。启动失败说明可执行文件或参数有问题；读取失败说明管道或消费者异常；Wait 返回 ExitError 则表示命令本身非零退出。用 CommandContext 设置取消边界，并把 stderr 保留下来，后续才有足够证据复盘。

常见问题

调用 StdoutPipe 后必须手动 Close 吗？

多数正常路径不必手动关闭，Cmd.Wait 会关闭由它创建的管道。重点是不要在读取完成前调用 Wait。

为什么只读取 stdout 也会卡住？

如果 stderr 没有被消费，子进程大量写错误输出时可能堵在 stderr。需要分别读取，或使用 CombinedOutput 接受合并输出。

能不能先 Wait 再读管道？

使用 StdoutPipe 或 StderrPipe 时不应这样做。先启动读取任务并让其完成，再调用 Wait，才能避免关闭管道时截断读取。