子进程取消

使用 exec.CommandContext 超时后，主命令退出并不等于它创建的所有后代进程都退出。默认情况下，Go 把取消动作绑定到 cmd.Process，调用的是该进程的 Kill；如果这个进程又启动了脚本、管道或孙进程，后代是否收到信号取决于操作系统和你的进程组策略。

官方地址：https://pkg.go.dev/os/exec

因此排查“子进程还在”时，先看取消边界，再看 Wait 是否被调用，最后决定是否需要平台相关的进程树回收。WaitDelay 能限制等待进程退出或 I/O 管道关闭的时间，但它不是跨平台的“杀掉所有后代”开关。

CommandContext 到底取消了什么

CommandContext 保存传入的 Context，并默认设置一个 Cancel 函数。Context 结束时，这个函数对已经启动的 cmd.Process 调用 Kill。它解决的是“Go 当前 Cmd 对应的进程需要停止”，不是“沿着进程树递归广播取消”。

ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel() // 无论命令提前结束还是超时，都释放计时器资源

cmd := exec.CommandContext(ctx, "sh", "-c", "worker --follow")
output, err := cmd.CombinedOutput()
if err != nil {
    // ctx.Err 用来判断是超时/取消，ExitError 用来判断命令自身退出失败。
    if errors.Is(ctx.Err(), context.DeadlineExceeded) {
        return fmt.Errorf("命令超时: %w", err)
    }
    return fmt.Errorf("命令执行失败: %w", err)
}
fmt.Println(string(output))

这段代码的取消对象是 sh 这个直接进程。若 sh 已经启动 worker，worker 是否继续运行不能只靠这段 Go 代码推断。尤其是 shell、构建工具和脚本包装器经常会再派生进程，看到父进程结束后，不能把“没有返回错误”理解成进程树已经清空。

为什么 Wait 返回了，后代进程还可能存在

cmd.Wait 等待的是直接子进程退出，并且还会等待 Go 为标准输入、输出和错误建立的复制协程完成。CombinedOutput 内部也会等待命令和输出收集结束。它关注的是 Cmd 的生命周期，不负责替你枚举系统中的后代进程。

还要注意两个容易混淆的现象：

• 直接进程已死：默认 Cancel 可能已经杀掉了 cmd.Process，但它创建的后代没有收到同一个取消动作。
• I/O 仍未结束：后代如果继承了 stdout 或 stderr 的文件描述符，即使直接进程退出，管道仍可能保持打开，让等待看起来像“卡住”。

Go 当前文档中的 WaitDelay 正是为两类延迟提供上限：Context 取消后子进程迟迟不退出，或进程已经退出但 I/O 管道没有关闭。超时后，Go 会终止仍在等待的直接进程并关闭相关管道；返回值可能是 exec.ErrWaitDelay。这能收敛 Wait 的等待时间，却不改变进程树管理规则。

ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel() // 让命令完成后及时释放 Context 关联资源

cmd := exec.CommandContext(ctx, "sh", "-c", "worker --follow")
cmd.WaitDelay = 500 * time.Millisecond // 给退出和管道收尾一个有限宽限期

if err := cmd.Run(); err != nil {
    // ErrWaitDelay 表示等待边界触发，不等同于“所有后代都已退出”。
    if errors.Is(err, exec.ErrWaitDelay) {
        return fmt.Errorf("命令收尾超时: %w", err)
    }
    return fmt.Errorf("命令失败: %w", err)
}
return nil

先画进程树，再决定是否需要额外回收

如果执行的是一个不会再派生进程的单一可执行文件，默认行为通常足够：Context 结束，直接进程被终止，Wait 收尾。若执行的是 shell、脚本、编译器驱动器或会启动长期 worker 的程序，就要把进程关系单独看待。

Go 提供 Cmd.SysProcAttr 作为操作系统相关启动属性的入口，但具体的进程组、信号和作业对象写法并不跨平台通用。不要把 Linux 的进程组代码直接当成 Windows 方案，也不要只修改 Cancel 却没有定义“这一批进程”的边界。

把取消、回收和观测拆成三个判断

实际工程里，可以用下面的顺序减少误判：

1. 取消：Context 是否结束，默认 Cancel 是否作用于直接进程。
2. 回收：是否调用了 Run、Output 或显式 Wait，以及是否设置了合理的 WaitDelay。
3. 观测：记录命令入口、超时原因和退出错误；若怀疑后代残留，要在目标操作系统上观察进程组，而不是只看 Go 返回值。

func runWithDeadline(parent context.Context, name string, args ...string) error {
    ctx, cancel := context.WithTimeout(parent, 5*time.Second)
    defer cancel() // 确保调用方取消或函数返回时都释放 Context

    cmd := exec.CommandContext(ctx, name, args...)
    cmd.WaitDelay = time.Second // 防止异常 I/O 让 Wait 无限等待

    if err := cmd.Run(); err != nil {
        // 先保留原始错误，再补充 Context 状态，便于区分超时与退出码。
        if ctx.Err() != nil {
            return fmt.Errorf("命令被取消: %w; 原因: %v", err, ctx.Err())
        }
        return fmt.Errorf("命令退出失败: %w", err)
    }
    return nil
}

这段通用包装适合“只管理一个直接命令”的场景。若命令会创建需要整体停止的后代，应该继续补上目标平台的进程组方案、信号处理和清理责任，并把它们作为这个包装器的明确契约，而不是依赖 CommandContext 的默认语义。

结论：超时不等于递归杀树

“子进程取消”最关键的判断是：CommandContext 默认取消的是 Cmd 直接绑定的进程，WaitDelay 约束的是退出与 I/O 收尾等待，两者都没有自动承诺清理完整后代树。没有派生进程时，默认方案简单可靠；存在 shell、脚本或长期 worker 时，必须把进程组和平台差异纳入设计。

相关问题

设置了超时后为什么还会卡在 Run？

直接进程可能已经退出，但后代仍持有输出管道；也可能是清理动作本身需要等待。可以用 WaitDelay 限制这类收尾等待，再针对进程树单独处理。

WaitDelay 能不能杀掉所有子进程？

不能把它当成递归杀树机制。它主要限制直接命令退出和关联 I/O 管道的等待，后代进程的清理仍需要操作系统层面的进程组或作业管理策略。

只检查 ctx.Err 就够了吗？

不够。ctx.Err 说明 Context 是否超时或被取消，命令错误还可能来自自身退出码、启动失败或 I/O 问题；应保留原始错误并结合退出状态判断。