Go exec.CombinedOutput 为什么可能占用过多内存

我第一次遇到这个问题，是把一个“通常只返回几行文本”的外部命令接进服务后，某次异常输入让进程输出持续增长。代码没有明显的循环泄漏，但服务的内存曲线跟着命令输出一起上升。后来回头看，真正的原因并不神秘：exec.Cmd.CombinedOutput 的职责就是把标准输出和标准错误完整合并后，以 []byte 返回。

如果命令输出可能很大，或者只需要实时记录而不需要完整结果，就不要把 CombinedOutput 当成默认模板。让 Stdout、Stderr 直接写入目标，或用两个 Pipe 并发读取；只有在输出有明确上限且确实要整体解析时，才适合完整缓冲。

CombinedOutput 为什么会让内存随输出增长

官方实现会创建一个 bytes.Buffer，把 Cmd.Stdout 和 Cmd.Stderr 都指向同一个缓冲区，命令结束后再返回 b.Bytes()。这意味着标准输出、标准错误以及缓冲区扩容期间的临时空间，都可能在命令完成前同时存在。

cmd := exec.Command("sh", "-c", "printf 'out\\n'; printf 'err\\n' >&2")
// CombinedOutput 会把 stdout 与 stderr 合并到同一个 []byte 中。
combined, err := cmd.CombinedOutput()
if err != nil {
    // 命令退出非零时，输出仍可能包含定位问题所需的信息。
    return fmt.Errorf("命令执行失败: %w，输出: %s", err, combined)
}
fmt.Printf("合并输出: %s", combined)

这个 API 的“占用过多”不是它偷偷开启了另一份日志缓存，而是返回值的契约决定了它必须把完整内容留到调用方接收。输出越大，[]byte 就越大；调用方如果再做字符串转换、JSON 封装或日志拼接，还会产生额外副本。

先判断：你需要完整结果，还是只需要把输出送出去

我现在会先问三个问题，而不是直接把 CombinedOutput 换成另一个 API：

• 后续是否要把整段输出交给 JSON 解析器、正则或其他完整输入接口？如果是，完整缓冲可能合理，但要给输出设置业务上限。
• 是否只需要把输出写进日志、文件或终端？如果是，优先直接设置 Stdout 和 Stderr。
• 是否要边读边解析、统计或提取少量字段？如果是，使用 Pipe，并让 stdout 与 stderr 同时被消费。

一个常见误区是只把 CombinedOutput 换成 Output。Output 仍然会把标准输出完整返回，只是标准错误的处理方式不同，并不能解决“大量输出常驻内存”这个根因。

只记录日志时，让命令直接写入目标

当我不需要在 Go 代码里重新解析完整结果时，会把两个输出流分别交给日志目标。这样 Go 进程不再维护一个随输出增长的完整 []byte。

func runToLog(ctx context.Context, name string, args ...string) error {
    cmd := exec.CommandContext(ctx, name, args...)
    // 直接交给调用进程的输出目标，避免在 Go 进程内聚合全部字节。
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

    if err := cmd.Run(); err != nil {
        var exitErr *exec.ExitError
        if errors.As(err, &exitErr) {
            // ExitError 只说明命令失败；详细输出已经流向日志目标。
            return fmt.Errorf("外部命令退出失败: %w", err)
        }
        // 启动失败、复制输出失败等错误也要继续向上返回。
        return fmt.Errorf("运行外部命令失败: %w", err)
    }
    return nil
}

这段写法适合压缩、编译、导出等输出可直接进入日志系统的任务。它的代价是调用方不再拥有一份完整返回值；如果需要保存审计记录，应让日志系统或文件承担持久化，而不是再用 io.ReadAll 把内容收回来。

需要边读边处理时，两个 Pipe 要同时消费

如果输出要被解析器逐段处理，就用 StdoutPipe 和 StderrPipe。两个管道都可能持续产生数据，顺序读取其中一个会让另一个管道塞满，子进程也可能因此无法继续运行。所以读取动作要并发进行。

func streamCommand(ctx context.Context, name string, args ...string) error {
    cmd := exec.CommandContext(ctx, name, args...)

    stdout, err := cmd.StdoutPipe()
    if err != nil {
        return fmt.Errorf("创建 stdout 管道失败: %w", err)
    }
    stderr, err := cmd.StderrPipe()
    if err != nil {
        return fmt.Errorf("创建 stderr 管道失败: %w", err)
    }
    if err := cmd.Start(); err != nil {
        return fmt.Errorf("启动命令失败: %w", err)
    }

    var wg sync.WaitGroup
    var readErr error
    var mu sync.Mutex
    copyStream := func(r io.Reader, w io.Writer) {
        defer wg.Done()
        if err := io.Copy(w, r); err != nil {
            // 两个读取 goroutine 共享错误槽，写入时加锁。
            mu.Lock()
            if readErr == nil {
                readErr = err
            }
            mu.Unlock()
        }
    }

    wg.Add(2)
    go copyStream(stdout, os.Stdout)
    go copyStream(stderr, os.Stderr)
    // 先等两个管道读完，再 Wait；StdoutPipe/StderrPipe 的文档明确要求如此。
    wg.Wait()
    waitErr := cmd.Wait()
    if readErr != nil {
        return fmt.Errorf("读取命令输出失败: %w", readErr)
    }
    if waitErr != nil {
        return fmt.Errorf("命令退出失败: %w", waitErr)
    }
    return nil
}

这里的关键不是“用了 goroutine 就一定更省内存”，而是把输出交给消费方，避免在调用方形成完整聚合结果。消费方仍然可以把每行送入解析器、计数器或脱敏日志；如果解析器本身把全部数据存起来，内存问题只是转移了位置。

想保留诊断信息时，给缓冲设置边界

有些任务既不能丢掉错误摘要，又不应该保留几百 MB 的完整输出。这时可以给写入目标做上限，或者只保留前缀与后缀。重点是“限制发生在读取过程中”，不要先 CombinedOutput 得到完整结果后再截断。

func runWithLimit(ctx context.Context, name string, args ...string) ([]byte, error) {
    cmd := exec.CommandContext(ctx, name, args...)
    var limited bytes.Buffer
    // LimitReader 让诊断缓冲最多接收固定字节数，避免无界增长。
    limitedWriter := &limitedWriter{dst: &limited, max: 64 * 1024}
    cmd.Stdout = limitedWriter
    cmd.Stderr = limitedWriter

    err := cmd.Run()
    if limitedWriter.truncated {
        // 让调用方知道内容不完整，不能把摘要误当成完整日志。
        limited.WriteString("\\n[输出已截断]\\n")
    }
    return limited.Bytes(), err
}

上面的 limitedWriter 只代表一种工程策略：实际项目里可以使用已有的限长 Writer，或实现 Write 方法记录是否超过上限。若必须同时记录 stdout 和 stderr 的来源，就不要简单合并到同一个缓冲区，而应给两路分别设置限额。

我现在的选择清单

几个容易混淆的问题

CombinedOutput 会不会只缓存标准错误？

不会。它把标准输出和标准错误合并到同一个缓冲区；如果只想拿标准输出，Output 仍然会缓冲标准输出，但两者的内存风险都取决于输出规模。

用了 StdoutPipe 后能不能直接调用 Run？

不建议。官方文档明确说明，使用 StdoutPipe 或 StderrPipe 时，应先 Start，完成管道读取后再 Wait；直接调用 Run 会破坏这个使用约束。

命令失败时是不是一定要保存完整错误输出？

不一定。生产系统通常更需要有限摘要、退出状态和可追踪的日志位置。是否保存完整输出，应由输出上限、合规要求和排障成本共同决定。

回到最初的内存曲线，真正的修复不是机械替换 API，而是先决定输出的生命周期：完整结果就明确限制规模，持续输出就直接消费，需要诊断就只保留有界摘要。这样 exec.Cmd 的输出策略才会和业务任务匹配。