Go exec.CommandContext 怎么自定义取消动作

exec.CommandContext 可以自定义取消动作：先创建 *exec.Cmd，再在调用 Start、Run 或 Output 之前替换 cmd.Cancel。默认取消会直接调用 Process.Kill；如果希望子进程先保存状态、关闭连接并退出，可以改为发送它支持的信号或关闭约定好的管道，同时设置 WaitDelay 作为强制回收兜底。

官方文档：https://pkg.go.dev/os/exec#Cmd

CommandContext 默认取消为什么不够灵活

CommandContext 会保存传入的 context.Context，并把 Cmd.Cancel 初始化为调用 Process.Kill。上下文先结束时，这种默认值能迅速终止进程，却不会给程序预留刷新缓冲区或清理临时状态的机会。它还把 WaitDelay 保持为零，因此默认不会给“取消后仍不退出”和“进程退出但管道未关闭”设置额外上限。

自定义取消前先确认外部程序真正支持什么关闭协议。在类 Unix 系统上，目标程序若处理 os.Interrupt，可以发送中断信号；跨平台服务也可以约定关闭标准输入、写入控制管道或调用本地网络关闭接口。Cancel 只负责触发动作，不会替目标程序实现优雅退出。

在启动前替换 Cmd.Cancel

下面示例把默认强制终止改为中断信号，并保留三秒兜底。示例假设 worker 能处理中断信号；不支持该信号的平台或程序，应替换为自己的关闭协议。

ctx, stop := context.WithTimeout(context.Background(), 10*time.Second)
defer stop()

cmd := exec.CommandContext(ctx, "worker", "--serve")

// 先请求目标程序协作退出；该赋值必须发生在 Run 或 Start 之前。
cmd.Cancel = func() error {
	if cmd.Process == nil {
		return os.ErrProcessDone
	}
	err := cmd.Process.Signal(os.Interrupt)
	if errors.Is(err, os.ErrProcessDone) {
		// 告诉 Wait：进程已经结束，不要把取消回调本身当成新故障。
		return os.ErrProcessDone
	}
	return err
}

// 协作退出超过三秒后，Wait 会用 Process.Kill 终止仍存活的进程。
cmd.WaitDelay = 3 * time.Second

if err := cmd.Run(); err != nil {
	// 这里统一记录上下文超时、退出码或取消动作产生的错误。
	log.Printf("worker 结束: %v", err)
}

Cancel 只会在命令已经成功启动且上下文结束时调用；如果 Start 本身失败，它不会执行。也不要在命令启动后再修改回调，否则会产生数据竞争或错过取消时机。

自定义 Cancel 与 WaitDelay 如何配合

两者解决的是不同问题。Cancel 选择协作式关闭动作；WaitDelay 从“上下文结束”或“Wait 观察到子进程退出”中较早的时点开始计时。超时后，如果子进程仍未退出，标准库会调用 Process.Kill；如果进程已经退出但通信管道仍打开，则关闭管道以解除读写等待。

ErrWaitDelay 不是“所有 WaitDelay 超时”的统一错误。官方语义要求：管道因 WaitDelay 被关闭、没有发生 Cancel，并且命令原本成功退出时，Wait 才用它代替 nil。进程因兜底 Kill 结束时，通常还会有进程状态或上下文相关错误。

常见问题

可以把 Cancel 设置为 nil 吗？

可以。上下文结束时将不会立即执行动作，但非零 WaitDelay 仍会生效。这适合不支持关闭信号、但预计会很快自行完成的命令。

只设置自定义 Cancel，不设置 WaitDelay 可以吗？

可以，但如果目标程序忽略信号，或它的后代进程一直占着输出管道，Wait 可能继续阻塞。需要明确回收上限时，应同时设置合理的 WaitDelay。

为什么取消后子进程退出码仍然重要？

因为自定义取消只是触发关闭请求。目标程序若以非零状态退出，Wait 仍应报告它的正常退出结果，便于区分“按协议结束”和“程序自身失败”。