如何在 Go 中实现对外部进程的退出信号监听

先说个关键结论：cmd.Wait() 对监听外部进程信号这事儿，基本指望不上。它不暴露进程的底层状态，更致命的是，Signal() 方法在 Windows 上永远返回 nil，即使 Linux 下也高度依赖内核实现——这就不太可靠了。

真正靠谱的做法是绕开 Wait()，直接上 os.Process.Wait()，配合 syscall.WaitStatus 来解析原始的退出状态。这里有三个关键点：

• 必须主动调用 cmd.Start() 才能拿到 *os.Process
• 千万别用 cmd.Run() 或 cmd.Output()，它们内部会自动调 Wait()，把控制权直接交出去
• Linux/macOS 下用 syscall.WaitStatus 解析 sys.WaitStatus；Windows 则只能退而求其次，靠退出码大致推断（注意，没有可靠的信号映射）

用 os.Process.Wait() 提取真实退出信号（Linux/macOS）

调用 proc.Wait() 后，返回的值是 syscall.WaitStatus 类型（本质上是个 uint32），用它的 Signal() 方法就能拿到终止信号编号。但有个前提：只有进程确实是被信号终止（非正常退出）时，Signal() 才不是0。

cmd := exec.Command("sleep", "10")
if err := cmd.Start(); err != nil {
    log.Fatal(err)
}

state, err := cmd.Process.Wait()
if err != nil {
    log.Fatal(err)
}

if sig := state.Signal(); sig != 0 {
    log.Printf("process killed by signal: %v", sig) // 比如 syscall.SIGTERM
}

几个细节点需要注意：

• state.ExitStatus() 返回0是正常退出，非0表示 exit(code)，此时 Signal() 一定是0
• 先调用 state.Signaled() 判断是否由信号终止，能避免误读 Signal()
• 信号名字，Go 1.21 之后可以用 syscall.SignalName(sig) 转成字符串，旧版本就得自己手动映射了

实时监听外部进程被 Kill 的事件（不阻塞主线程）

如果你的需求是“进程一挂就立刻响应”，而不是傻等，那就用 goroutine + channel 把 Process.Wait() 包装起来，把信号或状态塞到 channel 里就好了。

done := make(chan *syscall.WaitStatus, 1)
go func() {
    state, _ := cmd.Process.Wait()
    done <- &state
}()

select {
case s := <-done:
    if s.Signaled() {
        log.Printf("got signal: %v", s.Signal())
    }
case <-time.After(5 * time.Second):
    log.Println("timeout, killing process")
    cmd.Process.Kill()
}

这里有三个小坑：

• channel 容量定成1，防止 goroutine 泄漏——进程退出了但没人收消息就麻烦了
• 一定要先检查 s.Signaled()，再读 s.Signal()，否则对正常退出进程调用 Signal() 虽然不会报错，但语义上完全错了
• goroutine 里别直接放 panic 或 log，错误处理应该交给调用方

Windows 下的信号兼容性限制

Windows 本身就没有 POSIX 那套信号模型，所以 os.Process.Wait() 返回的 WaitStatus 是模拟出来的。结果就是：Signal() 永远是0，Signaled() 永远是 false。你唯一能拿到的只有退出码。

比如 TerminateProcess() 触发时，退出码通常是 0xC000013A（代表 STATUS_CONTROL_C_EXIT）或 0xC0000142（DLL 初始化失败）。但这些数字跟标准信号完全不是一回事。

• 在 Windows 上，你没法精准区分操作是来自 Ctrl+C、任务管理器结束，还是父进程主动调 TerminateProcess
• 跨平台场景下，建议统一用退出码做 fallback 判断：比如 state.ExitStatus() == 0xC000013A 可以粗略视为用户中断
• 如果程序必须强信号语义，那就得换方案了——用进程间通信（socket 或 pipe），让子进程主动上报状态

说到底，信号监听其实是操作系统能力的映射，Go 只是做了层封装。Linux/macOS 下可以精确捕获，Windows 下就只能妥协。这个差异，在上线前一定要验证清楚，不然生产环境出问题定位起来会很头疼。