Go os/exec读取StdoutPipe和StderrPipe并发阻塞的修复方案

Go 程序调用外部命令时，如果先把 StdoutPipe 读完，再去读 StderrPipe，子进程持续输出错误日志就可能把第二条管道写满。父进程卡在第一路读取，子进程又等不到写入空间，最终表现为命令不退出。修复的核心是：Start 后同时消费两条管道，等读取完成，再调用 Wait；如果业务不需要区分两路内容，直接使用 CombinedOutput。

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

两个管道为什么会把父进程卡住

os/exec 不会替你调用 shell。创建命令后，子进程分别向标准输出和标准错误写数据，父进程通过两个 pipe 读取。常见错误是先执行 io.ReadAll(stdout)，读完后才处理 stderr。

当 stderr 产生大量诊断信息时，它的缓冲区会先达到上限。子进程阻塞在写 stderr，因而不再继续写 stdout，也没有机会退出；父进程则一直等待 stdout 的 EOF。这里的“并发”不是为了加速，而是为了让两条输出通道始终有消费者。

正确的生命周期：Start、读取、Wait

需要分开保留两路内容时，先取得两个 pipe，再 Start。启动成功后立即为两条管道各安排一个读取协程；两个读取协程都结束后再调用 Wait，并分别处理读取错误和进程退出错误：

package main

import (
    "bytes"
    "context"
    "fmt"
    "io"
    "os/exec"
    "time"
)

func runCommand(ctx context.Context) (string, string, error) {
    // 固定可执行文件和参数，避免把不可信输入拼进 shell 命令。
    cmd := exec.CommandContext(ctx, "worker", "--format", "json")

    stdout, err := cmd.StdoutPipe()
    if err != nil {
        return "", "", fmt.Errorf("创建 stdout 管道失败: %w", err)
    }
    stderr, err := cmd.StderrPipe()
    if err != nil {
        return "", "", fmt.Errorf("创建 stderr 管道失败: %w", err)
    }
    if err := cmd.Start(); err != nil {
        return "", "", fmt.Errorf("启动命令失败: %w", err)
    }

    var outBuf, errBuf bytes.Buffer
    readErr := make(chan error, 2)
    // 两路必须同时读取，防止任意一条输出管道被写满。
    go func() {
        _, copyErr := io.Copy(&outBuf, stdout)
        readErr 

这个顺序的关键不是把 Wait 放到最后几个字符，而是保证两路读取已经开始并且没有一条通道被遗漏。Go 官方文档也明确说明，使用 StdoutPipe 或 StderrPipe 时，不能在管道读取完成前调用 Wait；因此不应把它们和 Run 直接混用。

不需要分流时改用 CombinedOutput

如果日志只需要保留一份，不要求区分 stdout 和 stderr，手工管理两个 pipe 反而增加了阻塞和清理风险。CombinedOutput 会运行命令并返回合并后的标准输出与标准错误：

cmd := exec.CommandContext(ctx, "worker", "--format", "json")
// 不需要分离日志时交给 os/exec 统一收集两路输出。
combined, err := cmd.CombinedOutput()
if err != nil {
    // 保留合并日志，便于记录失败上下文，但不要把敏感参数写入日志。
    return fmt.Errorf("worker 执行失败: %w，输出=%s", err, combined)
}

需要结构化解析 stdout、把 stderr 单独写入审计日志，或者根据两路内容做不同告警时，才选择前面的双 pipe 方案。两种方式都不要把用户输入拼成 sh -c 字符串；参数应作为 exec.Command 的独立参数传入。

排查清单与风险边界

排查时先看进程是否仍在运行，再看哪一路输出增长，最后确认读取协程、上下文取消和 Wait 的错误是否被记录。不要只通过增加超时时间掩盖管道没有消费者的问题。

常见问题

只读 StdoutPipe 时也必须并发吗？

只有一路管道时通常不需要两个读取协程，但仍应在 Start 后读取完，再调用 Wait。如果还配置了 stderr 管道，就必须确保 stderr 同时有人消费。

能否把 Stdout 和 Stderr 指向同一个 bytes.Buffer？

可以，但失去分流能力。若只是合并结果，优先使用 CombinedOutput；若为了实时转发而共享 Writer，要确认 Writer 的并发写入约束。

为什么设置 context 超时后仍然感觉没有返回？

取消只负责触发进程终止，调用方仍要让读取协程结束并调用 Wait 回收状态。对会遗留子进程或文件描述符的命令，还需要在命令层面设计退出和清理策略。