Go os/exec读取子进程标准输出的资源管理

用 Go os/exec 读取子进程标准输出时，资源顺序比“拿到字符串”更重要：先调用 StdoutPipe，再 Start，持续读取管道，最后调用一次 Wait。不要在读取前 Wait，也不要在使用 StdoutPipe 时直接调用 Run。前者可能让管道提前关闭，后者无法让调用者控制读取完成的时机。

先选对读取方式，再决定资源边界

exec.Command 只负责准备命令。若结果体积可控且不需要实时消费，cmd.Output() 会替你启动、读取标准输出并等待结束，代码最短。需要同时收集标准输出和标准错误时，可以选择 CombinedOutput()，但它把两条流合并，无法再区分来源。

真正需要流式处理、解析增量 JSON 或限制单行大小时，才使用 StdoutPipe。这个 API 返回的是连接子进程标准输出的 io.ReadCloser；官方文档明确要求先完成读取，再调用 Wait。这也是本文示例的核心边界。

StdoutPipe 的安全顺序是 Start、读取、Wait

下面的封装把三个结果分开保留：读取管道失败说明本地 I/O 没完成，Wait 失败说明命令退出状态或复制过程异常，stderr 则是子进程给出的诊断文本。示例没有把管道读取交给另一个长期存在的 goroutine，因此退出和回收关系更清楚。

package main

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

func readStdout(ctx context.Context, name string, args ...string) (string, error) {
    // CommandContext 让超时或取消可以触发子进程的终止路径。
    cmd := exec.CommandContext(ctx, name, args...)
    var stderr bytes.Buffer
    cmd.Stderr = &stderr

    // StdoutPipe 只建立连接，Start 前不会真正得到子进程输出。
    stdout, err := cmd.StdoutPipe()
    if err != nil {
        return "", fmt.Errorf("创建stdout管道失败: %w", err)
    }
    if err := cmd.Start(); err != nil {
        return "", fmt.Errorf("启动子进程失败: %w", err)
    }

    // 先读到EOF，再Wait；不能反过来调用，避免丢失尾部输出。
    data, readErr := io.ReadAll(stdout)
    waitErr := cmd.Wait()
    if readErr != nil {
        return "", fmt.Errorf("读取stdout失败: %w", readErr)
    }
    if waitErr != nil {
        // stderr 只用于补充诊断，真正的退出结果仍以waitErr为准。
        detail := strings.TrimSpace(stderr.String())
        if detail != "" {
            return "", fmt.Errorf("子进程退出失败: %w；stderr: %s", waitErr, detail)
        }
        return "", fmt.Errorf("子进程退出失败: %w", waitErr)
    }
    return string(data), nil
}

这里不需要额外调用 stdout.Close() 才能让 Wait 生效：Wait 会在观察到命令退出后关闭由 StdoutPipe 建立的管道。若在读取失败后提前返回，应该把 Wait 放进明确的收尾路径，而不是让启动成功的命令无人回收。

读取、退出与超时要分别判断

“拿到了输出”不等于“命令成功”。例如命令可能写完部分标准输出后以非零状态退出，这时 io.ReadAll 没有错误，但 Wait 会返回 *exec.ExitError。反过来，输出管道自身出错，也不能被一个退出码覆盖。

生产代码的三个资源检查点

第一，输出可能很大时不要无条件 io.ReadAll；可改用 bufio.Scanner、io.Copy 或带上限的读取器，并明确超限后的终止策略。第二，使用 CommandContext 给外部命令设置超时，但要知道上下文取消只解决终止触发，仍要执行 Wait 完成回收。第三，子进程可能派生后代并持有输出描述符，此时可以结合 Cmd.WaitDelay 设置等待 I/O 的上限，并把 exec.ErrWaitDelay 作为可识别的异常记录。

常见问题

为什么调用了 StdoutPipe 还不能直接用 Run？

Run 会启动并等待命令，而 StdoutPipe 要求调用者先完成管道读取；两者的控制顺序冲突。使用 Start、读取、Wait。

只想拿到完整输出，是否还要手动调用 Wait？

不需要。Output 已经封装了启动、读取和等待；只有自行使用 StdoutPipe 时才需要管理这条生命周期。

stdout 和 stderr 都要实时读取怎么办？

分别取得两个管道并并发消费，等两个读取任务完成后再调用一次 Wait。同时制定输出大小和取消策略，避免任意一条流堵住子进程。