Go Cmd.StdoutPipe 启动顺序错误会丢掉子进程输出吗

我第一次遇到这个问题，是把子进程的输出交给 StdoutPipe 后，为了“确保命令已经结束”先调用了 Wait。结果读取端拿到的不是完整文本，而是管道关闭相关的错误。结论很明确：StdoutPipe 要在 Start 前调用；Start 成功后先读取 stdout，等读取完成再调用 Wait。如果在读取前 Wait，Go 会关闭这个管道，输出可能读不全，甚至直接读取失败。

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

先把 StdoutPipe、Start、读取、Wait 的职责分开

这四个动作经常被误写成“拿管道、等待命令、再读结果”，但它们的职责并不相同。StdoutPipe 在父进程侧创建一个 io.ReadCloser；Start 才启动子进程并把它的标准输出接到这条管道；读取动作负责把数据消费完；Wait 则等待进程退出、等待必要的 I/O 收尾，并释放关联资源。

所以顺序的核心不是记口诀，而是守住资源边界：创建读取端在启动前，读取发生在启动后，Wait 放在读取完成之后。官方实现还明确说明，Wait 会在看到命令退出后关闭管道。

用正确顺序读取子进程的完整 stdout

下面的示例使用 Unix-like 环境中的 printf 生成一段短输出，重点是调用关系，不是依赖某个业务命令。读大文本时可以把 io.ReadAll 换成 bufio.Scanner 或 JSON 解码器，但仍要保持同样的生命周期。

package main

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

func main() {
    // 示例命令只用于演示 stdout 管道；生产代码应替换为明确的可执行文件和参数。
    cmd := exec.Command("sh", "-c", "printf 'worker-output\\n'")

    // StdoutPipe 必须在 Start 前获取，返回父进程的读取端。
    stdout, err := cmd.StdoutPipe()
    if err != nil {
        log.Fatal(err)
    }

    // Start 只启动子进程，不等待退出；启动失败时不要继续读取。
    if err := cmd.Start(); err != nil {
        log.Fatal(err)
    }

    // 先消费完管道内容，避免随后 Wait 关闭读取端造成截断或读取错误。
    output, readErr := io.ReadAll(stdout)
    if readErr != nil {
        log.Fatal(readErr)
    }

    // 读取完成后再 Wait，同时得到子进程退出状态并释放资源。
    if err := cmd.Wait(); err != nil {
        log.Fatal(err)
    }
    fmt.Printf("%s", output)
}

这里的错误要分开处理：Start 失败说明进程没有正常启动；读取错误说明管道消费出了问题；Wait 返回的非空错误则可能是子进程退出码非零，或收尾 I/O 出错。把三者都包成“命令失败”，排查时会丢失关键信息。

定位 Wait 过早和 StdoutPipe 过晚的两类错误

最常见的错误写法是先 Start，紧接着 Wait，最后才从 stdout 读取。此时即使子进程确实产生过输出，也不能把它当成仍然可读的完整缓冲区：Wait 看到进程退出后会关闭父端管道，后续读取可能得到关闭错误，已经读出的部分也不应被当成完整结果。

另一类错误是把 StdoutPipe 放到 Start 之后。标准库会拒绝这个状态，常见错误文本是 exec: StdoutPipe after process started。这不是“输出为空”，而是 Cmd.Process 已经存在，命令的 I/O 拓扑不能再修改。

同时处理 stdout 和 stderr，避免生产环境卡住

只读 stdout 时，前面的顺序通常已经够用；但如果还调用了 StderrPipe，不要先完整读 stdout、再完整读 stderr。子进程可能先写满 stderr 管道，随后等待 stderr 继续被消费，而父进程却还在等待 stdout 结束，于是双方互相等。

更稳妥的做法是为 stdout 和 stderr 各启动一个读取协程，把读取错误通过 channel 汇总；两边都消费完后再调用一次 Wait。如果不需要区分两种输出，直接把 cmd.Stderr = cmd.Stdout 或使用 CombinedOutput 也能简化模型，但要接受 stdout 和 stderr 混在一起的代价。

我在代码评审里会用三项回归检查：StdoutPipe 是否早于 Start；所有管道是否在 Wait 前被消费；大输出和非零退出时，读取错误与退出错误是否分别记录。满足这三点，启动顺序导致的“输出丢失”通常就能排除。

相关问题

StdoutPipe 能不能和 Cmd.Run 一起用？

不建议。Run 内部会负责启动并等待，使用 StdoutPipe 时你需要在 Wait 前主动读取，因此应改成显式的 Start、读取、Wait。

Wait 返回 nil 就代表 stdout 一定完整吗？

不代表。只有在读取完成后再 Wait，并且读取端没有报错时，才可以把内容视为完整；退出成功只说明命令和相关收尾没有报告错误。

为什么小输出正常，大输出却卡住？

通常与 stdout 或 stderr 管道被写满有关。若同时连接两个管道，应并发读取；若不需要分流，可考虑 Output 或 CombinedOutput。

读取失败后还要调用 Wait 吗？

一般仍要调用一次 Wait 完成进程收尾，并记录它返回的错误；但不要为了“再试一次”重复调用 Wait，也不要忽略最初的读取错误。

我的结论：把 StdoutPipe 当成“读取端准备”，把 Start 当成“进程启动”，把读取当成“消费管道”，最后才由 Wait 收束生命周期。顺序一旦写反，丢失的不是某个神秘缓存，而是已经进入关闭边界的读取机会。