Go CmdContext 超时后为什么进程还在：子进程树、退出状态与回收验证

你在用 Go 标准库 `exec.Command` 绑定上下文做超时控制的时候，大概率碰到过这类反直觉的情况：`context` 超时之后，你的主程序已经拿到了超时返回，后续逻辑都走完了，之前通过 `CmdContext` 启动的子进程却还在系统后台正常运行，完全没有被终止。我们顺着子进程树生成、信号传递、资源回收的全链路把这个问题说透。

`CmdContext` 触发超时后，Go 标准库仅会向直接创建的那一层子进程发送终止信号，默认不会递归杀死该子进程自身派生出来的所有后台子进程，若父进程没有主动执行子进程状态回收逻辑，已经退出的子进程也会变成僵尸进程残留，直到父进程退出后由系统 init 进程接管回收。

很多 Go 服务会用 exec.CommandContext 给外部命令加一个 2 秒或 5 秒的上限。超时后，程序日志里出现了 signal: killed，于是大家很容易认为“命令和它启动的所有进程都已经结束”。这个判断并不可靠：CommandContext 负责取消命令关联的进程，Shell 或命令再启动的孙进程可能继续占用管道、文件或 CPU。

先把“超时”拆成三个结果看

下面这三个结果经常在同一条日志里出现，但它们表达的含义不同。

因此排查时别急着把所有异常都归到“超时”。先分别记录开始时间、取消时间、Wait 返回时间和实际子进程的退出状态，后面的结论才站得住。

CmdContext 实际取消的是谁

exec.CommandContext(ctx, name, arg...) 把命令和一个 context 绑定。当 context 被取消时，标准库会调用命令的取消动作；默认取消动作是结束关联的进程。这里的关键词是“关联的进程”，不是“进程树”。

如果直接启动一个不会再派生子进程的程序，行为通常很直观。问题往往出现在这一层：

cmd := exec.CommandContext(ctx, "sh", "-c", "sleep 30")
err := cmd.Run()
fmt.Printf("ctx=%v wait=%v\n", ctx.Err(), err)

Go 等待的是 sh 这一个命令。Shell 启动的 sleep 可能继承标准输入输出管道；父 Shell 被结束后，sleep 是否退出、何时退出，要看操作系统和进程组行为，不能从 Run 的返回值猜出来。

用一个可复查的小实验区分父进程和后代

可以把命令包装成一个短时实验，重点不是执行什么业务，而是观察四个时间点：启动、截止、Wait 返回、后代 PID 消失。实验命令应使用开发机已有的安全工具，生产代码不要把任意用户输入直接拼进 sh -c。

ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()

cmd := exec.CommandContext(ctx, "sh", "-c", "sleep 30")
started := time.Now()
err := cmd.Run()
finished := time.Now()

fmt.Printf("started=%s finished=%s ctx=%v err=%v\n",
    started.Format(time.RFC3339Nano),
    finished.Format(time.RFC3339Nano),
    ctx.Err(), err)

这里能确认父命令的等待何时结束，但还不能确认 sleep 是否仍在运行。若要做完整验证，应在测试环境记录子进程 PID，随后用进程树工具和管道关闭状态复核；不要只用一条“命令结束”的日志作为证据。

为什么进程树会让回收变得复杂

当命令经过 Shell、脚本解释器或启动器时，链路可能是 Go 进程 → Shell → 工作进程。每一层都可能继承环境变量、标准流和文件描述符。父层退出后，后代仍持有写端时，读取端就可能迟迟收不到 EOF，表现为 Go 代码已经进入错误处理，另一个 goroutine 却还在等待输出。

我更建议先减少层级：能直接调用二进制，就不要为了传几个参数改成 sh -c；能用参数数组，就不要拼接一整段命令字符串。确实需要一棵进程树时，再把“如何结束进程组”作为平台相关实现单独测试，而不是把它藏在通用超时函数里。

生产代码应该记录哪些退出证据

最少记录命令名的安全摘要、开始和结束时间、context 错误、Wait 错误类型、退出码或信号，以及 stdout/stderr 是否正常关闭。不要把完整用户参数和敏感环境变量直接写入日志。

err := cmd.Run()
result := struct {
    ContextError error
    WaitError    error
    Elapsed      time.Duration
}{
    ContextError: ctx.Err(),
    WaitError:    err,
    Elapsed:      time.Since(started),
}

if result.ContextError != nil {
    // 先记录截止时间，再判断 Wait 的具体返回值。
    log.Printf("command deadline reached: elapsed=%s wait=%v",
        result.Elapsed, result.WaitError)
}

如果业务必须确保后代进程也结束，就要为 Unix 和 Windows 分别实现进程组/作业对象策略，并用集成测试验证：超时后没有残留 PID、管道最终收到 EOF、临时文件能删除、下一次调用不会继承旧资源。跨平台代码不能用一套信号名硬套所有系统。

常见问题：几个容易混淆的判断

看到 signal: killed 就能确定没有孙进程了吗？

不能。它通常说明被等待的进程收到了结束信号，但没有替你证明所有后代都退出。

context 超时后还要调用 cancel 吗？

要。即使 deadline 已经触发，调用 cancel 仍是释放 context 相关资源的标准写法。

把命令改成 sh -c 会更容易控制吗？

通常不会。它增加了一层进程和解析规则，只有确实需要 Shell 语法时才使用，并把进程组回收纳入测试。

Wait 返回 nil 就表示业务成功吗？

只表示被等待的命令以零状态退出。业务输出、生成文件和后代进程仍应按业务契约单独核对。

落地前的检查清单

• 是否可以直接启动目标程序，避免不必要的 Shell 层？
• 超时日志是否同时记录了 ctx.Err() 与 Wait 错误？
• 是否验证过 stdout/stderr 在后代进程场景下最终能关闭？
• Unix 与 Windows 的进程组回收是否分别有集成测试？
• 超时后是否检查残留 PID、临时文件和下一次调用的资源隔离？

把“调用返回”与“资源已经清干净”分开验证，才是处理 Go 外部命令超时最稳妥的边界。遇到残留进程时，先画出实际的父子链路，再决定是减少 Shell 层、控制进程组，还是调整业务超时。