Go os/exec Cmd 怎样限制子进程输出总量

给 Cmd.Stdout 和 Cmd.Stderr 设置共享的有界 Writer，在同一个计数预算内保存输出前缀；首次发现超限字节时取消 CommandContext，并继续丢弃消费管道数据直到 Run 返回。这样既限制保存量，又明确发起进程停止，而不是只给无限增长的缓冲区事后截断。

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

迁移目标：从完整收集改为有界前缀

假设服务调用一个外部转换器，正常只输出少量信息，但异常时可能持续打印诊断文本。原先把完整输出收集成字节切片，会让父进程承担不受控的保存成本。本次迁移只改变输出收集策略：约定 stdout 与 stderr 的字节总预算，超限返回明确错误，并保留有限前缀用于排查。

这个限制针对父进程收到并保存的数据，不是子进程在操作系统层面“绝对不能再写一个字节”的配额。取消生效前可能还有在途输出，子进程也可能有自己的缓冲。因此实现应明确区分保存上限、超限检测和停止请求。

旧写法问题：截断保存不等于停止进程

只对 Output 或 CombinedOutput 的结果切片做截断，发生在完整收集之后，已经来不及约束保存过程。只用 io.LimitReader 读取前 N 字节然后停止，也不一定合适：仍在写输出的子进程可能被写满的管道阻塞，父进程如果再等待它退出，就可能互相等待。

另一个误区是两路各限制 N 字节，却把它称为“总共 N 字节”。如果要合计额度，两路就必须使用同一个预算状态；如果要保留来源，可以由两个带来源标签的 Writer 共享同一个计数器，仍需处理并发。

新写法：stdout 与 stderr 共用一个预算

下面是可放入项目的封装示例。program 和 args 应由调用方按业务许可选择，函数不会调用 shell 解释字符串。示例没有执行任何外部命令，也不提供虚构运行日志。

package boundedexec

import (
    "context"
    "errors"
    "fmt"
    "os/exec"
    "sync"
    "time"
)

var ErrOutputLimit = errors.New("子进程输出超过上限")

type capture struct {
    mu sync.Mutex
    prefix []byte
    used int
    exceeded bool
    cancel context.CancelFunc
}

func (c *capture) Write(p []byte) (int, error) {
    c.mu.Lock()
    defer c.mu.Unlock()

    // 固定缓冲区只保存预算内的前缀，不按输入持续增长。
    keep := len(p)
    remaining := len(c.prefix) - c.used
    if keep > remaining {
        keep = remaining
    }
    copy(c.prefix[c.used:], p[:keep])
    c.used += keep
    if keep  16

缓冲区在开始时一次性分配为 limit 字节，后续只把剩余额度内的前缀复制进去。恰好写满预算尚不算超限；只有又看见额外字节才设置 exceeded。limit 为零时允许启动，但任何非空输出都会触发取消。16 MiB 和五秒都是示例策略值，应根据业务调整。

Write 返回原输入长度和 nil，表示当前块已经被处理，包括被丢弃的部分。若返回短写而没有错误，就违反 Writer 的约定；这里不靠写入错误终止复制，而是显式取消上下文，因此两路输出仍可被消费。

os/exec 对非文件 Writer 使用管道和复制逻辑。相同且可比较的 Writer 对象会获得串行 Write 调用保证；示例仍加锁保护共享状态，便于明确计数与读取的一致性。保存的是合并流前缀，不能据此推定两路输出的严格时间顺序，也不能区分每一段属于哪一路。

管道读取：两路都要消费，进程也要回收

本例直接给 Cmd 赋 Writer，让 Run 管理输出复制和等待。如果改为手工使用 StdoutPipe 和 StderrPipe，应先取得两路管道，再 Start，并发消费两路，完成读取后再 Wait。不要先读完一路才读另一路，否则未消费的那路可能写满；也不要在管道未读完前调用 Wait。

超限后的停止策略也必须保留回收环节。CommandContext 默认的 Cancel 会调用所启动进程的 Kill；它不是跨平台的整棵进程树终止方案。如果转换器还会启动后代进程，需要额外的平台相关管理，不能因为 Run 已返回就宣称所有后代已经结束。

WaitDelay 在上下文结束或观察到子进程退出后开始计时，用来限制某些退出和管道未关闭带来的延迟。它不是输出字节配额，也不能解除任意用户 Writer 中永远不返回的 Write。本例的 Writer 只复制和丢弃，不执行网络写入或其他长期阻塞动作。

错误分类和迁移清单

超限时底层可能同时出现被终止进程的退出错误。封装优先返回 ErrOutputLimit，让上层明确知道输出策略已触发；未超限时继续返回启动或退出错误。超时单独识别，避免把一切失败都写成“命令执行失败”。若需要同时保留多种原因，可扩展结构化结果，而不是依赖错误字符串匹配。

迁移时应在项目里覆盖无输出、少量输出、恰好上限、超限、只写 stderr、两路混写、超时和启动失败等情况。本文没有运行这些检查，也不把示例当成通过证明。返回的前缀可能截在 UTF-8 字符或日志记录中间，展示层应按截断数据处理，并遵守原输出的隐私边界。

相关问题

可以保证子进程总共只产生 N 字节吗？

不能。示例保证收集缓冲区只保存预算内的前缀，并在观察到超限时发起取消；在途和子进程自身缓冲不是同一个限制层。

stdout 和 stderr 要保留为两个结果怎么办？

用两个输出视图共享同一个锁和总计数，并分别保存被允许的片段。两路独立缓冲区若各自使用完整预算，会扩大合计保存量。

WaitDelay 可以代替 context 超时吗？

不能。它的计时有触发条件。没有输出又一直不退出的进程，仍需超时或其他取消条件。