Go exec.Cmd.Cancel 怎么优雅终止子进程

Go 里想在超时后“优雅”终止外部命令，关键不是直接调用 cmd.Process.Kill()，而是把取消分成两层：先让 Cmd.Cancel 发送子进程能处理的退出信号，再用 WaitDelay 限制收尾时间。CommandContext 默认会把 Cancel 设为 Kill，所以如果需要清理临时文件、刷新缓冲区或关闭连接，就应该在 Start 前覆盖它。

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

下面的示例只展示终止策略，不把示例输出当作真实运行截图。

先分清 CommandContext 的默认取消行为

当关联的 context 到期时，Go 会调用 cmd.Cancel。默认实现是 Process.Kill，它的优点是确定性强，缺点是子进程没有机会执行自己的清理逻辑。自定义取消函数通常要在 cmd.Start() 前设置；Start 失败时，Cancel 不会被调用。

用自定义 Cancel 发送可处理的退出信号

在类 Unix 系统上，可以先发送 SIGTERM，让子进程捕获信号并完成清理；如果目标程序在约定时间内仍不退出，再交给 WaitDelay 的强制兜底。自定义函数不要调用 Wait，因为 Wait 不能和其他等待并发执行。

package main

import (
    "context"
    "errors"
    "fmt"
    "os"
    "os/exec"
    "syscall"
    "time"
)

func run(ctx context.Context) error {
    // 用一个可捕获的退出信号替代默认 Kill，给子进程清理资源的机会。
    cmd := exec.CommandContext(ctx, "sh", "-c", "trap 'exit 0' TERM; sleep 30")
    cmd.Cancel = func() error {
        if cmd.Process == nil {
            // Start 失败或进程尚未创建时，不再重复发送信号。
            return os.ErrProcessDone
        }
        err := cmd.Process.Signal(syscall.SIGTERM)
        if errors.Is(err, os.ErrProcessDone) {
            // 进程已经退出时，把它视为取消已完成。
            return os.ErrProcessDone
        }
        return err
    }
    // 取消后最多等待这段时间，超时由 exec 负责 Kill 并关闭管道。
    cmd.WaitDelay = 2 * time.Second

    if err := cmd.Start(); err != nil {
        return fmt.Errorf("start child: %w", err)
    }
    err := cmd.Wait()
    if err != nil {
        return fmt.Errorf("wait child: %w", err)
    }
    return nil
}

这里的 sh 仅用于说明“收到信号后退出”的协议，实际项目应换成目标程序自己的关闭接口或信号约定。Windows 不支持同样的 Unix 信号语义，应按目标程序提供的控制方式设计取消动作。

用 WaitDelay 给退出和管道收尾设上限

WaitDelay 不是优雅退出信号，它是最后一道时间边界。context 取消后，如果子进程没有退出，计时结束会调用 Kill；如果子进程已经退出但 stdout、stderr 管道仍未关闭，也会关闭管道以解除读写阻塞。默认值为零时，管道可能一直等到派生孙进程也关闭文件描述符。

因此，使用 StdoutPipe 或 StderrPipe 时要同时安排读取协程和退出策略；不能为了“等输出完整”而无限期阻塞 Wait。如果确实不需要实时读取，直接把输出连接到 os.File 往往更容易收尾。

按错误类型判断取消是否成功

取消后收到错误并不等于策略失败。若进程因信号退出，通常会看到 *exec.ExitError；如果自定义 Cancel 返回了普通错误，即使命令随后以成功状态退出，Wait 也可能返回该错误。只有把“进程已结束”包装为 os.ErrProcessDone，才表示这类取消错误可以被忽略。

errors.Is(err, context.DeadlineExceeded) 用来识别 context 到期；errors.Is(err, exec.ErrWaitDelay) 则说明等待边界触发，重点排查子进程是否忽略信号以及是否留下了未关闭的输出管道。不要只比较错误字符串，也不要在 Cancel 中再次调用 Wait。

生产使用时检查平台和进程树边界

这套方案只保证“被 Cmd 直接启动的进程”获得取消机会。若它又派生了孙进程，单独给父进程发信号不一定能结束整棵进程树；需要由目标程序提供级联关闭协议，或在具体平台上建立进程组策略。另一个常见坑是把 WaitDelay 当成业务超时：它只负责 exec 的收尾，不会替代 context 的业务截止时间。

可以按这张清单落地：先用 context 表达业务超时；再覆盖 Cancel 做温和终止；设置一个小于上游请求容忍度的 WaitDelay；最后统一记录 ExitError、ErrWaitDelay 和取消原因。这样既给正常退出留机会，也不会让一个失控子进程拖住整个 goroutine。

常见问题

Cancel 可以直接调用 cmd.Wait 吗？

不建议。Wait 不允许并发调用，取消函数只负责发信号、关管道或发起关闭请求，让外层唯一的 Wait 负责回收资源。

把 Cancel 设为 nil 就能优雅退出吗？

不会。这样 context 到期时不会立即采取动作，只会等待非零 WaitDelay 生效，适合预期很快自行结束的程序，不适合作为通用优雅终止方案。