子进程输出

用 Go 的 os/exec 读取子进程输出时，最容易踩到的坑是把 StdoutPipe 和 CombinedOutput 写在同一个 Cmd 上。结论很直接：不要这样组合。CombinedOutput 会自己把 stdout 和 stderr 绑定到同一个缓冲区；StdoutPipe 则要求 stdout 由一个独立的读取管道承接，两者会争用同一个输出位置。

官方资料：https://pkg.go.dev/os/exec

如果目标是拿到一份完整文本，直接用 CombinedOutput；如果目标是边运行边消费 stdout，就使用 StdoutPipe，按 Start → Read → Wait 的顺序处理。下面只围绕这一个选择展开。

为什么两个方法不能一起调用

Cmd 的 Stdout 和 Stderr 是输出目的地。调用 StdoutPipe 时，标准输出会被设置为一条需要由调用方读取的管道；而调用 CombinedOutput 时，标准输出和标准错误都会被设置为同一个 bytes.Buffer。

因此，下面的代码不是“先拿管道、再顺便收集完整输出”，而是在第二次调用时触发了冲突：

package main

import (
    "fmt"
    "os/exec"
)

func main() {
    cmd := exec.Command("sh", "-c", "printf 'out\\n'; printf 'err\\n' >&2")

    // 先让 stdout 由独立管道承接，准备流式读取。
    _, err := cmd.StdoutPipe()
    if err != nil {
        panic(err)
    }

    // 错误：CombinedOutput 还要自己设置 stdout 和 stderr。
    _, err = cmd.CombinedOutput()
    fmt.Println(err)
}

冲突的根因不是 shell 命令本身，而是 Cmd 已经有了 stdout 绑定。标准库源码会在 CombinedOutput 发现 Stdout 非空时直接返回错误；反过来，先调用 CombinedOutput 再调用 StdoutPipe 也一样不成立。

只要完整结果，就选 CombinedOutput

如果子进程输出量可控，调用方只关心命令结束后的完整文本，CombinedOutput 是最短也最清楚的写法。它会把 stdout 和 stderr 合并，适合把完整输出放进日志、错误信息或后续解析。

package main

import (
    "fmt"
    "os/exec"
)

func runOnce() error {
    cmd := exec.Command("sh", "-c", "printf 'result\\n'; printf 'warning\\n' >&2")

    // CombinedOutput 一次性收集 stdout 和 stderr，调用后不能再复用 cmd。
    output, err := cmd.CombinedOutput()
    if err != nil {
        // 失败时保留合并后的文本，便于记录子进程的诊断信息。
        return fmt.Errorf("command failed: %w; output=%s", err, output)
    }

    fmt.Printf("complete output: %s", output)
    return nil
}

这里的代价也很明确：输出会留在内存里，且 stdout 和 stderr 的边界会消失。如果你要区分两条流，或命令可能产生大量输出，就不要为了省几行代码选择它。

需要实时消费 stdout，就用 StdoutPipe

StdoutPipe 适合长时间运行的命令、实时展示进度，或把输出持续写入文件和解析器。它的生命周期顺序不能交换：先拿到管道并启动进程，再把管道读完，最后调用 Wait。

package main

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

func streamOutput(ctx context.Context) error {
    cmd := exec.CommandContext(ctx, "sh", "-c", "printf 'line-1\\n'; printf 'line-2\\n'; printf 'warn\\n' >&2")

    // stdout 走管道，stderr 单独收集，避免丢失错误流。
    stdout, err := cmd.StdoutPipe()
    if err != nil {
        return fmt.Errorf("create stdout pipe: %w", err)
    }
    var stderr bytes.Buffer
    cmd.Stderr = &stderr

    // Start 只负责启动；不要在拥有 StdoutPipe 时改用 Run。
    if err := cmd.Start(); err != nil {
        return fmt.Errorf("start command: %w", err)
    }

    var output bytes.Buffer
    // 先持续读取 stdout，再 Wait，让管道中的数据有机会被消费。
    if _, err := io.Copy(&output, stdout); err != nil {
        return fmt.Errorf("read stdout: %w", err)
    }

    // Wait 会等待进程退出和相关 I/O 收尾，并返回退出状态错误。
    if err := cmd.Wait(); err != nil {
        return fmt.Errorf("wait command: %w; stderr=%s", err, stderr.String())
    }

    fmt.Printf("stdout=%s", output.String())
    return nil
}

示例把 stdout 收进 bytes.Buffer 只是为了演示读取过程；真正的流式场景可以把 io.Copy 的目标换成文件、网络响应或自定义解析器。若需要同时实时消费 stdout 和 stderr，应分别设置处理路径，必要时并发读取，不能把一条流的读取顺序当成另一条流的完成信号。

不要把 Run 当成 StdoutPipe 的快捷写法

官方文档特别强调：使用 StdoutPipe 时调用 Run 是不正确的。原因在于 Run 会把启动和等待合在一起，而管道读取必须在等待完成前进行；正确写法是显式拆开 Start 和 Wait。

同理，Output 也不是 StdoutPipe 的替代品。Output 会自行设置 stdout 收集结果，因此它和已经设置了 stdout 管道的 Cmd 也存在同类冲突。可以把三个 API 记成下面这张表：

错误处理要分清三类失败

使用管道时，至少要区分创建管道失败、读取失败和进程退出失败。前两类通常说明 I/O 或上下文取消影响了读取；最后一类通常会表现为 *exec.ExitError，表示进程启动了但返回了非零退出状态。不要只检查最终的 Wait 错误，就把所有问题都称为“输出为空”。

如果只是希望记录失败时的诊断信息，CombinedOutput 会很方便；如果必须保留 stdout/stderr 的独立语义，则分别配置它们，并在错误路径中同时保存两边的信息。还要注意：一个 Cmd 在调用 Start、Run、Output 或 CombinedOutput 后不能复用，重试时应创建新的命令对象。

最后按这个判断即可

• 只要完整文本，不需要边运行边处理：使用 CombinedOutput。
• 只要 stdout 的完整结果，并希望失败时获得 stderr：使用 Output。
• 需要实时消费、控制内存或保留两条流：使用 StdoutPipe，并显式执行 Start → Read → Wait。
• 不要在同一个 Cmd 上组合 CombinedOutput 与 StdoutPipe，也不要在使用管道时调用 Run。

相关问题

StdoutPipe 之后为什么要先读再 Wait？因为 Wait 会等待进程及相关 I/O 收尾，先读才能确保管道中的数据被消费。

CombinedOutput 能区分 stdout 和 stderr 吗？不能；它的语义就是把两条流合并到一个结果中。

子进程输出很大时还适合 CombinedOutput 吗？通常不适合，应改为管道或文件等流式目标，避免完整结果长期占用内存。