Go exec.Cmd 怎样捕获标准输出和标准错误

我在 Go 里第一次接外部命令时，最容易误判的一件事是：程序明明执行了，为什么只拿到了标准输出，诊断信息却不见了？根因通常不是命令没有写错误流，而是只给 exec.Cmd.Stdout 绑定了接收器，Cmd.Stderr 仍然没有被保存。需要分开处理时，直接给两个字段绑定不同的 bytes.Buffer；只需要一份完整日志时，再使用 CombinedOutput。

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

要分别捕获标准输出和标准错误，就把 Cmd.Stdout、Cmd.Stderr 分别指向两个 Writer；命令返回非零状态并不等于两条流里的内容不存在，先读出缓冲内容，再根据 error 判断退出结果。

只看到一条输出时，先看影响面

exec.Command 只负责准备一个 Cmd。真正运行时，标准输出和标准错误是两个独立的文件描述符。Stdout 或 Stderr 为 nil 时，命令对应的输出不会自动进入你的字符串变量；因此“业务结果有了、错误详情没有”往往是接线不完整。

我会先把问题拆成两个判断：调用方是否需要保留流的边界，以及命令失败时是否仍要读取已经产生的内容。前者决定使用两个 Writer 还是 CombinedOutput，后者决定不能因为 Run 返回错误就丢掉缓冲区。

用两个 bytes.Buffer 分别收集输出

下面的示例让子进程主动写入两条流，并故意以非零状态结束。父进程仍然先读取两个缓冲区，再用 errors.As 判断是否拿到了 exec.ExitError。这样既能看到正常输出，也能保留失败诊断。

package main

import (
	"bytes"
	"errors"
	"fmt"
	"os"
	"os/exec"
)

func main() {
	// 子进程分支只用于演示两条输出流，避免把用户输入拼进 shell 命令。
	if len(os.Args) > 1 && os.Args[1] == "--emit" {
		fmt.Fprintln(os.Stdout, "normal output")
		fmt.Fprintln(os.Stderr, "diagnostic output")
		os.Exit(2)
	}

	var stdout, stderr bytes.Buffer
	cmd := exec.Command(os.Args[0], "--emit")
	// 两个 Writer 分开绑定，分别保留 stdout 和 stderr 的边界。
	cmd.Stdout = &stdout
	cmd.Stderr = &stderr

	err := cmd.Run()
	// 命令失败时也要先读取已经写入缓冲区的内容。
	fmt.Printf("stdout=%q\n", stdout.String())
	fmt.Printf("stderr=%q\n", stderr.String())
	if err != nil {
		var exitErr *exec.ExitError
		// ExitError 可以继续提供退出状态，便于区分命令失败和启动失败。
		if errors.As(err, &exitErr) {
			fmt.Printf("exit code=%d\n", exitErr.ExitCode())
		}
	}
}

这里的关键不是把错误当成“没有输出”，而是把它拆成两个结果：stdout 和 stderr 是内容，err 是启动或退出状态。只要子进程已经启动并写过数据，即使最后退出码不是 0，缓冲区仍然值得保留。

需要实时读取时，再使用 StdoutPipe 和 StderrPipe

如果命令输出很大，或者调用方要边读边展示日志，可以改用 StdoutPipe 与 StderrPipe。这时不要先把 stdout 全读完再读 stderr：子进程可能在 stderr 写满后等待，而父进程还在等待 stdout 结束，最终形成互相等待。两个管道应由独立的读取任务同时消费，最后再调用 Wait 收尾。

type streamResult struct {
	name string
	data []byte
	err  error
}

cmd := exec.Command("your-program", "--report")
stdoutPipe, err := cmd.StdoutPipe()
if err != nil {
	return err
}
stderrPipe, err := cmd.StderrPipe()
if err != nil {
	return err
}

if err := cmd.Start(); err != nil {
	return err
}

	results := make(chan streamResult, 2)
	// 两条管道并发读取，避免大输出时只读一侧造成阻塞。
	go func() {
		data, readErr := io.ReadAll(stdoutPipe)
		results 

这段片段需要在文件顶部补充 io 导入，并把两个读取结果按 name 放回各自变量。实际项目中还应把读取错误和 waitErr 一并返回。StdoutPipe、StderrPipe 更适合流式处理，但代码管理成本高于两个内存缓冲区。

只需要一份日志时，用 CombinedOutput

当调用方只关心“命令产生的完整文本”，不需要判断某一行原本来自 stdout 还是 stderr，可以写成：

cmd := exec.Command("your-program", "--report")
// CombinedOutput 适合统一收集日志，但会丢失两条流的边界。
output, err := cmd.CombinedOutput()
if err != nil {
	// output 仍可能包含命令失败前写入的诊断信息。
	fmt.Printf("command failed: %v\noutput=%s\n", err, output)
}

CombinedOutput 的优点是调用简单；代价是无法再可靠地区分哪部分是正常输出、哪部分是错误输出。如果日志需要结构化入库、分别展示或按流做告警，仍然选择两个 Writer 或两个 Pipe。

我会保留的复查清单

• 只绑定 Stdout 时，Stderr 不会自动进入同一个缓冲区。
• 调用 StdoutPipe 和 StderrPipe 后，要并发读取，不能依次读完两个大流。
• Run 返回错误后，先查看两个缓冲区，再根据 ExitError 或启动错误做分支。
• Cmd 在执行过 Start、Run、Output 或 CombinedOutput 后不要复用。
• os/exec 不会自动调用 shell；不要为了拼接参数而把不可信输入直接塞进 shell 字符串。

对我来说，最稳妥的默认选择是两个 bytes.Buffer：输出量可控、需要分别记录两条流时，用它们保持边界；只有日志确实不分流时，才用 CombinedOutput；输出可能很大或要实时展示时，再升级到双 Pipe 并发读取。

相关问题

为什么命令失败了，stdout 仍然有内容？
退出错误描述的是最终状态，不会抹掉进程在退出前已经写入的 stdout 或 stderr。

什么时候不该使用 CombinedOutput？
需要分别保存正常结果与诊断信息、按来源展示日志或对 stderr 单独告警时，不要合并两条流。