Go exec.Cmd 读取 stdout stderr 阻塞的处理方式

一种很容易误判的 Go 卡顿是：子进程似乎结束了，cmd.Wait() 却迟迟不返回。常见根因不是 Wait 自己死锁，而是父进程只消费 stdout，子进程继续向 stderr 写数据，另一条管道被填满后双方一起等待。

不需要区分两路输出时，把 stdout 和 stderr 交给 Cmd.Run 或 CombinedOutput；必须分开处理时，Start 后同时读取两条 Pipe，等读取结束后只调用一次 Wait。

先把“Wait 卡住”拆成三个现场

排查时把父进程、子进程和两条 OS 管道分开看。不要先读完 stdout 再读 stderr：子进程可能主要写 stderr，导致 stdout reader 等 EOF，而子进程被 stderr 缓冲区反压。

阻塞不是 Wait 独立造成的，而是两条管道互相等待读取

StdoutPipe 和 StderrPipe 返回连接到命令输出的读取管道。使用它们时，不能在读取完成前调用 Wait，也不应再用 Run 代替生命周期管理。

排查先问三件事：是否同时读取两路？是否在 reader 结束前 Wait？是否混用了 Run 与 Pipe？

不需要分流时，让 Run 负责并发复制

如果业务只需要得到两路文本，不要求边读边解析，也不要求把两路日志发送到不同系统，最稳妥的写法是把两个 Writer 交给 Cmd。内部复制逻辑会在命令运行期间持续消费输出，Run 返回时再统一检查退出状态。

var stdout, stderr bytes.Buffer

cmd := exec.Command("worker", "--emit-both")
cmd.Stdout = &stdout // 让 exec 内部持续收集标准输出
cmd.Stderr = &stderr // 独立收集错误输出，避免第二条管道无人消费

if err := cmd.Run(); err != nil {
    // 退出非零时仍保留两路文本，便于定位子进程原因。
    return fmt.Errorf("worker failed: %w; stderr=%s", err, stderr.String())
}
fmt.Println(stdout.String()) // 成功后再读取完整结果。

大输出会占用内存；只需合并两路内容时也可用 CombinedOutput。需要实时解析或转发时，再使用分流读取。

分流读取时，Start、双 reader 与 Wait 要有明确边界

需要分别处理两路内容时，顺序应固定为：先取得两条 Pipe，再 Start，随后为 stdout 和 stderr 各安排一个 reader，等两路 reader 都结束后调用一次 Wait。两个 reader 必须并发存在，不能用一个循环先读完一条再读另一条。

var wg sync.WaitGroup
var stdout, stderr bytes.Buffer
readErr := make(chan error, 2)

read := func(r io.Reader, dst *bytes.Buffer) {
    defer wg.Done()
    // 每条管道由独立 reader 消费，避免 stdout 反过来等待 stderr。
    _, err := io.Copy(dst, r)
    readErr 

readErr 强调：读取失败与子进程退出失败不是同一种错误。生产代码应汇总通道结果，并给错误标注 stdout 或 stderr。

超时和防复发清单：不要用一个错误覆盖所有现场

命令可能不退出，或在取消后仍让管道保持打开。可用 exec.CommandContext 绑定取消信号，并按任务设置 Cmd.WaitDelay。超时返回时同时记录 context、Wait 和两路输出的末尾内容。

相关问题

使用 StdoutPipe 后还能直接调用 Cmd.Run 吗？

不建议。Pipe 的读取生命周期需要由调用方安排；如果只是收集结果，请改用 Writer 或 CombinedOutput。

为什么小输出正常，大输出才阻塞？

小输出可能还没有填满某一路管道缓冲区，问题被容量掩盖；输出变大后，子进程会在写入端等待父进程读取。

Wait 返回 nil 就代表两路输出完整了吗？

在正确的 Writer 或 Pipe 生命周期下，Wait 会等待相关复制或读取完成；但自定义 reader 的错误仍应单独记录，不能只看退出码。