Go 启动外部命令超时后为什么进程还在：CommandContext、子进程与 Wait 收尾

服务端用 Go 启动外部命令时，日志里最容易误导人的现象是：CommandContext 返回超时错误了，但系统里还能看到一个进程。原因通常不是上下文失效，而是把“命令对象收到取消”误当成“进程树里的所有进程已经退出”。

CommandContext 默认会在上下文结束时调用命令进程的 Kill，但它不会替应用自动清理任意子进程；无论使用 Run 还是 Start，都要让 Wait 完成收尾，涉及子进程时还要单独设计退出边界。

先把现象拆开：超时、父进程和子进程不是一个状态

先看最小调用链。CommandContext 创建命令，Start 启动它并填入 Process，上下文截止后触发取消，最后由 Wait 等待退出和 I/O 收尾。

ctx, cancel := context.WithTimeout(context.Background(), 200*time.Millisecond)
defer cancel()

cmd := exec.CommandContext(ctx, "sh", "-c", "sleep 2")
if err := cmd.Start(); err != nil {
    log.Fatal(err)
}

err := cmd.Wait()
fmt.Printf("process=%v err=%v ctx=%v\n", cmd.Process, err, ctx.Err())

这里的 sleep 2 是由 sh 启动的 child。上下文结束后，Go 会对命令关联的 Process 执行默认取消动作；Wait 返回，说明这个 Cmd 的生命周期已收口，不代表所有由它派生的程序都已经结束。

为什么 Start 之后一定要 Wait

Start 只负责发起执行，成功后 cmd.Process 才可用于记录 PID 或参与取消策略。它不等待退出，也不替代资源回收。官方文档要求启动成功后调用 Wait，而 Wait 还会等待非文件型标准输入输出复制完成。

func runOnce(ctx context.Context) error {
    cmd := exec.CommandContext(ctx, "sh", "-c", "printf ready")
    var output bytes.Buffer
    cmd.Stdout = &output

    if err := cmd.Start(); err != nil {
        return err
    }
    if err := cmd.Wait(); err != nil {
        return err
    }
    fmt.Println(output.String())
    return nil
}

检查点有两个：第一，Start 成功后无论命令正常退出还是上下文取消，都必须到达 Wait；第二，输出读取完成后再把结果交给上层。只调用 Start、随后立即返回，是“看见进程还在”和资源未收尾的常见来源。

用上下文状态判断：不要只靠错误字符串

超时后的错误通常是 *exec.ExitError 或包装后的执行错误，不能把错误文本里出现的“killed”当成全部判断依据。把命令结果和 ctx.Err() 一起记录，才能区分截止时间、主动取消和命令自身失败。

err := cmd.Wait()
switch {
case errors.Is(ctx.Err(), context.DeadlineExceeded):
    log.Printf("command timeout: err=%v", err)
case errors.Is(ctx.Err(), context.Canceled):
    log.Printf("command canceled: err=%v", err)
case err != nil:
    log.Printf("command failed: err=%v", err)
default:
    log.Printf("command completed")
}

这里的核对顺序很重要：先等 Wait，再结合上下文状态记录结果。若把上下文刚结束就当作“后台没有任何进程”，监控和故障处理会得到过于乐观的结论。

遇到 child 时，先确认命令边界再选方案

当外部命令会创建 child，例如 shell 再启动工具，父进程被终止后，子进程可能暂时继续运行。Go 的 CommandContext 默认取消动作针对命令的 Process；它没有跨平台、自动递归清理所有后代进程的承诺。

最稳妥的优先级是：尽量直接启动真正的业务可执行文件，避免不必要的 shell；让业务命令自己接收取消并清理子任务；在必须管理进程组的场景，再按部署平台实现单独的进程组或作业对象策略。不要把某个 Unix 信号写法当成 Windows 和 Linux 都相同。

验证时至少记录父命令的 PID、启动参数、上下文截止原因和 Wait 返回值。若要确认 child 是否残留，应在目标平台用受控测试命令观察，而不是只看 Go 函数是否返回。

生产代码的四个收尾检查

命令失败和超时怎么区分

同时保留 err 与 ctx.Err()。上下文是超时或取消时，给调用方返回可识别的超时/取消语义；命令自身退出非零时，保留退出错误用于诊断。

为什么不建议把 Cmd 放进共享结构体

Cmd 包含运行期状态，应由一次调用独占。把它跨请求复用或交给多个 goroutine，会让 Start、Wait 和输出读写的边界变得不可核对。

输出很大时要注意什么

不要无上限地把标准输出积进内存。根据任务选择临时文件、受控缓冲或流式消费，并仍然保证 Wait 完成；如果输出管道没人消费，命令也可能因写满而阻塞。

相关问题：怎样判断这次命令真的收口

只看到 CommandContext 返回错误，能说明进程树清空了吗

不能。它最多说明这次 Cmd 的取消和 Wait 已返回；派生的 child 是否退出要按命令设计和目标平台另行核验。

Run 和 Start 加 Wait 哪个更安全

简单命令用 Run 更紧凑；需要读取 Process、分开处理输出或记录阶段时用 Start 加 Wait。两者都不能绕过子进程边界问题。

发布前的最小验收

把一次执行验收成四项：CommandContext 的截止时间确实可触发；Start 后一定调用 Wait；日志同时记录 Process、上下文状态和最终错误；出现 child 时有目标平台上的进程残留检查。这样“超时但进程还在”就从模糊现象变成了可定位的生命周期问题。