Go os/exec用 Context 终止超时命令的处理方案

执行外部命令时，最稳妥的超时处理是把 context.WithTimeout 和 exec.CommandContext 放在同一条调用链里：前者定义截止时间，后者负责在上下文结束时触发取消。命令返回后还要先判断 ctx.Err()，这样才能把“超时被终止”和“命令自己返回非零”分开记录。

超时控制不是另起一个 goroutine 调用 Kill 就结束了。调用方仍要等待命令收尾、释放 cancel，并明确默认取消动作只覆盖当前 Cmd 进程的边界。

先把超时责任交给 Context

WithTimeout 返回派生 Context 和取消函数。取消函数要在函数返回时执行，即使命令很快完成，也能释放定时器。超时时间应由业务任务传入，而不是散落在命令拼接代码中。

ctx, cancel := context.WithTimeout(parent, 3*time.Second)
defer cancel() // 及时释放超时计时器，正常完成和超时都要执行

cmd := exec.CommandContext(ctx, "sh", "-c", "sleep 5; printf done")
out, err := cmd.CombinedOutput() // 等待命令退出，并收集标准输出和错误输出
if ctx.Err() != nil {
	// Context 先结束时，优先记录超时或上游取消原因。
	return fmt.Errorf("命令未在截止时间内完成: %w", ctx.Err())
}
if err != nil {
	// Context 仍正常时，这通常是启动失败或命令返回非零。
	return fmt.Errorf("命令执行失败: %w", err)
}
return nil

这段代码的关键不是 sleep，而是错误判断顺序。命令被 Context 取消后，CombinedOutput 往往也会返回错误；先检查 ctx.Err() 才不会把超时误报成普通业务失败。

影响面：Run 返回了，进程一定清理了吗

常见故障是任务函数已经返回，但外部程序仍占用 CPU 或文件描述符。CommandContext 会在 Context 完成时调用 Cmd 的取消函数，默认取消函数是对当前进程调用 Kill；它不会自动理解 shell 的管道、脚本再启动的孙进程或平台特有的进程组。

因此，单个可控命令可以直接使用上面的方案；如果命令实际启动了进程树，就要把进程组、信号传播、输出管道关闭和回收策略单独设计，不能仅凭一个超时参数宣称“全部子进程已结束”。

按时间线定位三类结果

如果使用 Start 而不是 Run，则必须在启动后调用 Wait。只调用 Start 再等待 Context，会把回收责任留在调用方，容易出现僵尸进程或管道未关闭。

修复动作：把可观测信息写全

生产日志至少保留命令的安全摘要、开始时间、截止时间、耗时、ctx.Err() 和退出错误。不要把完整用户输入直接拼入 shell；os/exec 默认不经过 shell，也不会自动展开管道和重定向，确需 shell 时应单独评估参数边界。

输出可能很大时，不要无上限地使用 CombinedOutput。可改用受控的 bytes.Buffer 或截断写入器，并在超时后同时观察输出管道是否关闭。Go 新版本还提供 Cmd.WaitDelay 等收尾控制，但它不能替代对进程树和平台行为的设计。

上线前的回归清单

• 用一个明确会超时的命令验证 ctx.Err() 能被记录为 deadline exceeded。
• 用一个立即退出的命令确认正常结果不会被误判为超时。
• 用不存在的可执行文件覆盖启动失败路径。
• 检查 defer cancel()、Wait、输出关闭和进程树清理策略是否都有责任人。

结论是：WithTimeout + CommandContext + 正确等待 足以覆盖单个外部命令的常规超时场景；一旦命令通过 shell 或脚本形成进程树，就必须把取消传播和资源回收作为独立设计项。