Go exec.CommandContext 取消后如何确认子进程已退出

exec.CommandContext 取消的是“继续运行”的动作，不等于调用方已经观察到子进程退出。要确认退出，必须在 Start 成功后调用一次 cmd.Wait()，并把它的返回作为生命周期的最终结果。超时则看 ctx.Err()，普通非零退出则从 *exec.ExitError 的 ProcessState.ExitCode() 读取；两者不要混成一个布尔值。

为什么不能只监听 ctx.Done

监听 ctx.Done() 能知道截止时间已到，却不能证明操作系统已经回收了子进程，也不能替代 Go 对标准输入输出复制协程的收尾。官方文档说明，Wait 会等待命令退出，并等待相关 I/O 拷贝完成；它还负责释放 Cmd 关联的资源。

因此，正确的边界是：取消信号负责触发中断，Wait 负责确认退出。若程序在收到取消信号后立即返回，父进程可能继续处理下一项，而被杀掉的子进程或它持有的管道仍在收尾。

用 Wait 完成取消后的退出确认

下面的封装把 Wait 放入有缓冲通道。正常退出时直接读取等待结果；上下文结束时仍然继续读取同一个结果，保证函数返回前已经完成一次 Wait。

package main

import (
    "context"
    "errors"
    "os/exec"
)

type CommandResult struct {
    Err      error
    ExitCode int
    Canceled bool
    TimedOut bool
}

func resultFrom(waitErr error, ctxErr error) CommandResult {
    // -1 表示没有可用的普通退出码，例如启动失败或被信号终止。
    result := CommandResult{Err: waitErr, ExitCode: -1}
    if ctxErr != nil {
        // 上下文原因只描述取消来源，不替代 Wait 返回的命令错误。
        result.Canceled = true
        result.TimedOut = errors.Is(ctxErr, context.DeadlineExceeded)
    }

    var exitErr *exec.ExitError
    if errors.As(waitErr, &exitErr) && exitErr.ProcessState != nil {
        // 普通非零退出可读取退出码；被 Kill 时不同平台可能返回 -1。
        result.ExitCode = exitErr.ProcessState.ExitCode()
    }
    return result
}

func run(ctx context.Context, name string, args ...string) CommandResult {
    cmd := exec.CommandContext(ctx, name, args...)
    if err := cmd.Start(); err != nil {
        // Start 失败时没有启动成功的进程，不应调用 Wait。
        return resultFrom(err, nil)
    }

    done := make(chan error, 1)
    go func() {
        // Wait 只能调用一次，缓冲通道避免发送方被接收时机卡住。
        done 

这个模式的关键不是“开一个 goroutine”本身，而是取消分支不能直接返回。默认配置下，CommandContext 会把取消转换为对进程的 Kill；等到 Wait 返回后，才可以安全地进入下一次任务调度。

如何区分超时、取消和退出码

判断时建议保留三类信息：上下文原因、Wait 的错误、可读取的退出码。context.DeadlineExceeded 说明是截止时间触发，context.Canceled 说明是主动取消；*exec.ExitError 则代表命令没有以成功状态结束。被强制终止时，退出码不要当作跨平台稳定的业务码。

如果取消和命令自然退出恰好同时发生，两个分支可能同时就绪，精确的先后顺序本来就没有业务意义。工程上应把它记为“取消窗口内完成”，并以已经返回的 Wait 结果作为资源收尾依据。

WaitDelay 和输出管道的边界

如果给 Stdout 或 Stderr 接入管道、字符串构建器等非 *os.File 对象，Wait 还要等待相应的 I/O 循环结束。某个孙进程继承了输出描述符却迟迟不关闭时，看起来就像“子进程没有退出”。

较新的 Go 版本可以设置 cmd.WaitDelay，为子进程退出和 I/O 管道收尾设置上限。超过上限时可能得到 exec.ErrWaitDelay；这表示等待阶段超限，不应简单改写成普通退出码。若业务需要读取完整输出，应先设计好管道关闭和子进程树处理策略。

最后检查三件事：Start 成功后恰好调用一次 Wait；取消分支没有绕过 Wait；日志同时记录上下文原因、waitErr 和可用退出码。这样“取消后是否真的退出”的问题就从猜测变成了可判断的状态。

常见问题

调用 cancel() 后，ctx.Done 返回是不是代表进程已退出？

不是。它只代表取消信号已经广播；要确认子进程退出，仍需读取 cmd.Wait() 的结果。

Wait 返回 signal: killed 时还能拿到退出码吗？

可以尝试读取 ProcessState.ExitCode()，但被信号终止时常见结果是 -1，不要把它当作业务层固定编码。

为什么 Wait 还会等待很久？

除了进程本身，Wait 还可能在等待标准输入输出的复制循环；检查是否有子进程继承了管道描述符，并按需设置 WaitDelay。