Go进程收到SIGINT/SIGTERM后子进程未退出，是因为默认未启用进程组隔离且不自动透传信号；必须设置SysProcAttr.Setpgid=true创建独立进程组，并在捕获信号后调用syscall.Kill(-cmd.Process.Pid, sig)向整组发信，再wait等待退出。
Go进程收到SIGINT/SIGTERM后为什么子进程没退出
Go默认不会自动将信号转发给子进程，父进程捕获SIGINT或SIGTERM后若直接调用os.Exit()或让主goroutine退出，子进程会变成孤儿进程继续运行——这是最常被忽略的“不优雅”根源。
根本原因是：Go的os/exec.Cmd启动的子进程默认与父进程不在同一进程组，且未设置SysProcAttr.Setpgid = true，导致kill -- -pid（负PID杀进程组）失效；同时Go本身不自动透传信号。
- 必须显式启用进程组：
cmd.SysProcAttr = &syscall.SysProcAttr{Setpgid: true} - 必须手动监听信号，并向整个进程组发送相同信号（用负PID）
-
syscall.Kill(-pid, sig)中的-pid表示进程组ID，不是字面负号加变量值
如何用signal.Notify + syscall.Kill实现信号透传
核心逻辑是：监听指定信号 → 获取子进程的PGID（即其cmd.Process.Pid）→ 向进程组发送同类型信号 → 等待子进程退出 → 再退出主进程。
注意syscall.Kill对进程组的调用在Linux/macOS行为一致，但Windows不支持进程组概念，需单独处理（通常忽略或记录警告）。
立即学习“go语言免费学习笔记（深入）”；
- 监听信号时用
signal.Notify(c, os.Interrupt, syscall.SIGTERM)，避免漏掉Ctrl+C触发的SIGINT - 向子进程组发信号必须用
syscall.Kill(-cmd.Process.Pid, sig)，不是cmd.Process.Signal(sig)（后者只发给单个进程） - 发信号后应调用
cmd.Wait()阻塞等待子进程结束，防止主进程提前退出
go c := make(chan os.Signal, 1) signal.Notify(c, os.Interrupt, syscall.SIGTERM) sig := <-c syscall.Kill(-cmd.Process.Pid, sig) cmd.Wait() // 等子进程真正退出
exec.CommandContext配合signal.StopNotify是否够用
不够。虽然exec.CommandContext能在ctx取消时尝试杀死子进程，但它调用的是Process.Kill()（即SIGKILL），不可捕获、不可忽略、无法做清理——这和“优雅退出”目标相悖。
真正需要的是可中断的、可响应的信号传递，而非强制终结。因此CommandContext适合超时控制，但不能替代手动信号透传逻辑。
-
ctx, cancel := context.WithCancel(context.Background())后，cancel()只会触发cmd.Wait()返回，不发任何信号 -
cmd.Process.Kill()等价于kill -9，子进程来不及执行defer或os.Interrupthandler - 若坚持用Context，需额外起goroutine监听信号并主动调用
syscall.Kill(-pid, ...)
子进程本身不处理信号时怎么办
如果子进程是第三方二进制（如nginx、redis-server），它可能监听SIGHUP重载、SIGTERM退出，但默认不响应SIGINT——这时你转发SIGINT过去等于无效。
解决办法不是改子进程，而是统一使用它认可的终止信号。例如Nginx官方推荐用SIGTERM停止，systemctl stop也发SIGTERM。
- 查清子进程文档支持哪些信号：
man 7 signal或项目README - Go中只监听并透传它能处理的信号，比如只接
syscall.SIGTERM，忽略os.Interrupt或转为SIGTERM - 避免转发
SIGQUIT或SIGUSR1这类子进程未定义行为的信号
真正的优雅不在于转发得多，而在于转得准——信号语义匹配，才是进程协作的前提。
