Go exec.Cmd 输出管道不读取为什么 Wait 会阻塞

用 exec.Cmd.StdoutPipe 接管子进程输出时，Wait 不能无条件排在读取代码前面。子进程写入量较小时，管道尚未填满，错误可能暂时不暴露；输出一大，子进程会卡在写管道上，父进程又在等 Wait 返回，于是形成互相等待。正确顺序通常是 Start、消费 stdout、Wait。如果 stdout 和 stderr 都接成管道，两路还要同时消费。

Wait 为什么会被未读取的输出拖住

StdoutPipe 把子进程的标准输出接到一条操作系统管道：子进程持有写端，父进程拿到 io.ReadCloser 作为读端。管道不是无限队列，写端填满后，子进程的写操作会等待读端腾出空间。

这解释了“短输出正常、长输出阻塞”的假象。短输出可能刚好没有填满管道，子进程能够退出，Wait 也就返回；长输出让子进程停在写入处，父进程若先等待退出，就永远没有机会开始读取。这里真正的根因是输出消费与进程等待的时序，而不是 Wait 随机失效。

先 Start，再读取，最后 Wait

官方 os/exec 文档明确提醒，Wait 会在看到进程退出后关闭管道，因此使用 StdoutPipe 时不能把 Wait 放在所有读取完成之前。单路输出可以把读取放在当前 goroutine 中：

cmd := exec.Command("your-program", "--emit-report")
stdout, err := cmd.StdoutPipe()
if err != nil {
    return fmt.Errorf("创建 stdout 管道失败: %w", err) // 先保留管道创建错误
}

if err := cmd.Start(); err != nil {
    return fmt.Errorf("启动子进程失败: %w", err) // Start 成功后才开始消费
}

data, readErr := io.ReadAll(stdout) // 先把读端消费完，避免写端被填满
waitErr := cmd.Wait()               // 最后等待进程退出并回收资源
if readErr != nil {
    return fmt.Errorf("读取 stdout 失败: %w", readErr) // 读取错误与进程错误分开判断
}
if waitErr != nil {
    return fmt.Errorf("子进程退出失败: %w", waitErr)
}
fmt.Println(string(data))

这个顺序不是为了“让 Wait 更快”，而是让父进程持续给子进程的写端腾空间。读取错误和进程退出错误要分开保留：前者反映管道消费，后者反映命令本身的退出状态。

stdout 和 stderr 都接管时要并行消费

如果同时调用 StdoutPipe 和 StderrPipe，就有两条独立的管道。只读取 stdout 仍可能因为 stderr 写满而卡住，尤其是子进程把诊断信息大量写到标准错误时。常见做法是为两路各启动一个读取 goroutine，等待读取完成后再调用 Wait：

stdout, _ := cmd.StdoutPipe()
stderr, _ := cmd.StderrPipe()
if err := cmd.Start(); err != nil {
    return err
}

var out, errOut []byte
var outErr, errReadErr error
var wg sync.WaitGroup
wg.Add(2)
go func() { defer wg.Done(); out, outErr = io.ReadAll(stdout) }()   // 独立消费 stdout
go func() { defer wg.Done(); errOut, errReadErr = io.ReadAll(stderr) }() // 独立消费 stderr
wg.Wait()
waitErr := cmd.Wait() // 两路读完后再等待并回收命令
if outErr != nil || errReadErr != nil || waitErr != nil {
    return fmt.Errorf("输出读取或命令退出失败: stdout=%v stderr=%v wait=%v", outErr, errReadErr, waitErr)
}
_ = out
_ = errOut

示例省略了变量声明和业务处理，重点是两路消费关系。生产代码还应处理 StdoutPipe、StderrPipe 本身的错误，避免在半初始化状态继续启动。

不需要手动读取时，用更简单的输出方式

如果需求只是拿到最终文本，不需要边读边处理，可以让 Cmd 直接管理缓冲区：

var output bytes.Buffer
cmd.Stdout = &output // 让 exec 负责把标准输出复制到缓冲区
cmd.Stderr = &output // 合并诊断信息时再接到同一个目标
if err := cmd.Run(); err != nil {
    return fmt.Errorf("命令失败，输出为 %q: %w", output.String(), err) // 错误中保留可诊断输出
}
fmt.Print(output.String())

也可以使用 cmd.Output() 或 cmd.CombinedOutput()。它们适合有限输出；如果输出可能很大，应该改成流式消费并设置业务侧的大小限制，避免把整个结果无界地放入内存。

排查这类阻塞的检查清单

常见问题

为什么小命令调用 Wait 看起来也没问题？

因为小输出尚未填满管道，子进程可能已经退出。它没有证明顺序正确，只是没有触发容量上限。

读取 stdout 后还需要手动 Close 吗？

按 StdoutPipe 的文档约定，Wait 会在进程退出后关闭管道；关键是不要在读取完成前调用 Wait。若业务要提前终止读取，再明确设计关闭和进程终止的关系。

stdout 和 stderr 可以顺序读取吗？

不稳妥。任一路都可能先填满，优先为两路安排并行消费者，或把两路输出交给不会形成手动双管道等待的目标。