Go 怎么调用外部程序并分别接收标准输出和错误

在 Go 里调用外部程序，想把正常输出和错误输出分开保存，最直接的做法是给 exec.Cmd 的 Stdout、Stderr 分别绑定两个 io.Writer，然后调用 Run。如果输出量很大，或页面需要实时显示日志，再改用 StdoutPipe 和 StderrPipe，让两路读取器并行消费，并在读取结束后调用 Wait。

不要把整条命令拼成一个字符串交给 os/exec。用 exec.Command(name, arg...) 显式传参；小输出用两个 bytes.Buffer，大输出或实时日志用两条管道和独立读取协程。

分别接收两路输出的最小写法

外部程序的标准输出通常是正常结果，标准错误既可能是诊断日志，也可能伴随非零退出码出现。只要不需要边执行边展示，两个 bytes.Buffer 就足够：

package main

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

func main() {
    // 这里只为演示两路输出，生产环境不要把不可信输入拼进 sh -c。
    cmd := exec.Command("sh", "-c", "printf 'ready\\n'; printf 'cache miss\\n' >&2")

    var stdout, stderr bytes.Buffer
    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
        if errors.As(err, &exitErr) {
            fmt.Printf("exit error: %v\\n", exitErr)
        }
    }
}

这里的 sh -c 只是为了让示例同时产生两路内容；os/exec 本身不会自动调用 shell，也不会替你展开通配符、管道或重定向。业务参数应拆成独立字符串，例如 exec.Command("tool", "--input", fileName)，不要把用户输入拼成 shell 命令。

为什么不能用一个结果函数代替两路接收

Output() 的职责是运行命令并返回标准输出；当 Stderr 为空且命令返回 *exec.ExitError 时，错误对象可能带上标准错误内容，但这仍是“失败信息挂在错误对象上”，不是两个持续独立的输出通道。

CombinedOutput() 更简单，却会合并标准输出和标准错误。适合只需要一段诊断文本的命令，不适合要分别入库、分别着色或分别统计的场景。可以按下面这张表选 API：

输出很大或要实时读取时怎么接管管道

把 Writer 换成管道后，程序可以边读边处理，避免一次性把全部内容放进内存。两条管道应由不同的读取协程消费，否则某一路写满而无人读取时，子进程可能停在写操作上：

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

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

var out, diag []byte
var outErr, diagErr error
var wg sync.WaitGroup
wg.Add(2)
go func() { defer wg.Done(); out, outErr = io.ReadAll(stdout) }()
go func() { defer wg.Done(); diag, diagErr = io.ReadAll(stderr) }()
wg.Wait()

runErr := cmd.Wait()
if outErr != nil { return outErr }
if diagErr != nil { return diagErr }
if runErr != nil { return runErr }
fmt.Println(string(out), string(diag))

完整示例还需导入 io 和 sync，并把这段代码放进返回 error 的函数。官方文档特别强调：使用 StdoutPipe 或 StderrPipe 时，不能在管道尚未读完前调用 Wait，也不应继续用 Run 替代这套生命周期。

退出码、环境与命令边界要单独检查

Run 返回非空错误不只代表“程序没找到”：程序启动后以非零状态退出时，通常得到 *exec.ExitError；启动失败、复制输出失败也可能是其他错误。用 errors.As 取退出错误，再结合 stderr 判断原因，不要只比较错误字符串。

如果命令需要固定目录，设置 cmd.Dir；需要自定义环境时设置 cmd.Env，但要记得保留必要的父进程环境。需要超时或取消时使用 exec.CommandContext。另外，Go 1.19 起，LookPath 对解析到当前目录的可执行文件会返回满足 errors.Is(err, exec.ErrDot) 的错误，生产环境应显式写出可信路径或按安全策略处理。

相关问题

标准输出和标准错误能否绑定同一个 bytes.Buffer？

可以，但这样就无法按来源区分内容。若只是合并日志可以直接使用 CombinedOutput；需要分类时使用两个 Writer。

为什么使用 StdoutPipe 后还调用 Run 会出问题？

因为 Run 内部会负责启动并等待，而管道读取也需要由调用方在等待前完成。应改成 Start、读取管道、Wait 的顺序。

读取失败和外部程序退出失败先处理哪个？

先保留两路读取错误，再检查 Wait 返回值；读取错误说明数据搬运本身失败，退出错误说明子进程没有以成功状态结束，两者含义不同。