Go CommandContext 为什么子进程仍不退出

Go 的 exec.CommandContext 不是“递归杀掉所有后代进程”的开关。它把 Context 绑定到一个 Cmd，默认在上下文结束时调用这个命令对应进程的 Kill；如果命令通过 shell 又启动了孙进程，或者孙进程继续持有标准输出管道，外层看起来就会出现“子进程仍不退出”或 Wait 一直等的现象。

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

排查时先分开看三件事：直接子进程有没有收到取消、shell 派生的进程有没有一起结束、stdout/stderr 管道有没有关闭。通常最稳妥的修复是直接执行目标程序；必须管理一棵进程树时，再按平台设置进程组，并用 WaitDelay 限制 I/O 拖尾。

CommandContext 实际取消了哪一个进程

CommandContext 的输入链是 context.Context → Cmd → 直接子进程。上下文结束后，默认的 Cmd.Cancel 会对已经启动的命令调用 Process.Kill；这能结束 Cmd.Process，但不等于操作系统会自动遍历并终止它创建的所有后代。

例如下面的写法把 shell 当成了直接命令。shell 被结束后，shell 启动的 sleep 仍可能独立存在：

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

cmd := exec.CommandContext(ctx, "sh", "-c", "sleep 10")
err := cmd.Run()
if err != nil {
	// 取消通常会让 Run 返回上下文错误或进程退出错误。
	log.Printf("command finished: %v", err)
}

这里的关键不是把超时时间调得更短，而是确认 sh 和它启动的程序是否属于同一个需要回收的进程边界。Windows、Linux、macOS 的进程树控制方式也不完全相同，不能把某个平台的信号写法直接当成跨平台方案。

为什么进程结束了 Wait 还不返回

Run 内部会经历启动、等待进程退出和等待 I/O 拷贝。只要 Stdout 或 Stderr 不是普通文件，Wait 还要等对应的 I/O 循环完成。shell 派生的程序如果继承了管道写端，即使外层 shell 已经退出，读端也可能收不到 EOF。

因此，“进程列表里看不到父命令”与“Go 调用已经返回”不是同一件事。调用方还需要检查是否手动使用了 StdoutPipe、StderrPipe，是否在读取完成前调用了 Wait，以及后代进程是否继续持有管道。

让退出链完整的三种写法

第一选择是绕过 shell，直接执行目标程序，把参数作为独立参数传给 exec.CommandContext：

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

cmd := exec.CommandContext(ctx, "sleep", "10")
out, err := cmd.CombinedOutput()
if err != nil {
	// CombinedOutput 会同时收集标准输出和标准错误，适合短输出命令。
	if errors.Is(ctx.Err(), context.DeadlineExceeded) {
		return fmt.Errorf("命令超时: %w", ctx.Err())
	}
	return fmt.Errorf("命令失败: %w，输出=%s", err, out)
}

第二种是确实需要 shell 或一组协作进程时，在 Unix 平台创建自己的进程组，并在取消时按进程组发送信号。该做法必须放在平台相关文件中，结合项目实际的优雅退出信号和强制终止兜底；不要把 syscall.SysProcAttr 方案伪装成 Windows 通用代码。

第三种是处理“进程已经退出，但 I/O 管道迟迟不收口”。在支持该字段的 Go 版本中，可以设置 Cmd.WaitDelay，让 Wait 在上下文取消或观察到子进程退出后最多再等一段时间，随后关闭管道并终止仍未退出的子进程。它解决的是等待上限，不替代进程组设计。

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

cmd := exec.CommandContext(ctx, "sh", "-c", "sleep 10")
cmd.WaitDelay = 300 * time.Millisecond
if err := cmd.Run(); err != nil {
	// WaitDelay 只控制取消后的等待拖尾，不能保证 shell 的所有后代都被清理。
	log.Printf("command returned: %v", err)
}

按现象检查退出与资源回收

不要只看 context.DeadlineExceeded 就宣布“已经清理”。真正的复查结果应该同时包含：上下文原因、Run/Wait 错误、命令进程状态，以及使用管道时的读取协程是否结束。Wait 也不能被多个 goroutine 并发调用。

常见追问

把 CommandContext 换成 Command 再手动 Kill 会更可靠吗？

不一定。手动 Kill 仍然只针对你保存的那个 os.Process，而且更容易漏掉超时、Wait 和资源释放。先明确进程树和管道边界，再决定是使用默认取消、定制 Cancel 还是进程组。

WaitDelay 能不能替代杀掉孙进程？

不能。它是等待和 I/O 拖尾的上限控制；如果需要让一组后代一起退出，仍要使用目标平台支持的进程组、作业对象或其他生命周期管理方式。