cmd.Wait() 不能用于可靠信号监听，因其不暴露进程状态且Signal()在Windows上恒为nil；应改用os.Process.Wait()配合syscall.WaitStatus解析真实退出信号。
为什么 cmd.Wait() 不能直接用于信号监听
cmd.wait() 是阻塞调用，它只返回子进程的退出状态，不暴露底层的 os.process 或其 pid，也没法感知到进程是被 sigterm 还是 sigkill 终止的。更关键的是：如果外部进程被信号终止，cmd.wait() 返回的 *exec.exiterror 的 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() 才非零。
<pre class="brush:php;toolbar:false;">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) // e.g. syscall.SIGTERM
}
state.ExitStatus() 返回 0 表示正常退出；非 0 表示 exit(code)，此时 <code>Signal()为 0-
state.Signaled()可先判断是否由信号终止，避免误读Signal() - 信号名需用
syscall.SignalName(sig)转为字符串（Go 1.21+），旧版本需手动映射
如何监听外部进程被 kill 的实时事件（不阻塞主线程）
若你不想阻塞 goroutine 等待进程结束，而是希望“进程一挂就立刻响应”，得用 goroutine + channel 封装 Process.Wait()，并把信号或状态发到 channel。
<pre class="brush:php;toolbar:false;">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() 再读 <code>s.Signal()，否则对正常退出调用Signal()会返回 0（不是错误，但语义错误） - 不要在 goroutine 中直接 panic/log —— 调用方应负责错误处理
Windows 下的信号兼容性限制
Windows 没有 POSIX 信号模型。os.Process.Wait() 返回的 WaitStatus 在 Windows 上是模拟实现，Signal() 总是 0，Signaled() 总是 false。唯一能拿到的是退出码，而 TerminateProcess() 触发的退出码通常是 0xC000013A（STATUS_CONTROL_C_EXIT）或 0xC0000142（DLL init failed），但这些不是标准信号。
- 无法区分
Ctrl+C、任务管理器结束、父进程TerminateProcess - 建议在 Windows 上统一用退出码做 fallback 判断：
state.ExitStatus() == 0xC000013A可粗略视为用户中断 - 跨平台程序若需强信号语义，应改用进程间通信（如 socket、pipe）由子进程主动上报
信号监听本质是操作系统能力的投射，Go 只是封装。Linux/macOS 下可精确捕获，Windows 下只能妥协 —— 这个差异点，上线前必须验证清楚。
