Go语言不自动捕获信号，signal.Notify需显式调用且通道必须持续消费，否则SIGINT/SIGTERM无响应；常见错误是注册后主goroutine退出或未读通道，导致信号丢失。
Go 语言本身不自动捕获任何系统信号；signal.Notify 必须显式调用、位置正确、通道持续消费，否则 SIGINT 和 SIGTERM 都不会触发你的处理逻辑。
signal.Notify 为什么注册了却没反应
最常见原因是：只调用了 signal.Notify，但主 goroutine 立即退出或没读 channel。Go 运行时不会“记住”你注册过信号——它只是把匹配的信号往你给的 chan os.Signal 里塞，没人读，信号就丢。
- 错误写法：
signal.Notify(sigChan, syscall.SIGINT)后直接return或执行完http.ListenAndServe就结束 - 正确前提：注册必须在启动长期任务（如 HTTP server）之前完成
- 必须让某个 goroutine 持续读取
sigChan，例如for { - 别用
time.Sleep(1 * time.Hour)阻塞——不可靠，且无法响应后续信号
监听哪些信号才够用
本地开发按 Ctrl+C 是 SIGINT，但生产环境（Kubernetes、systemd、CI 脚本）发的几乎全是 SIGTERM（kill -15）。漏掉它，程序上线后根本收不到退出通知。
- 底线组合：
syscall.SIGINT、syscall.SIGTERM - 可选补充：
syscall.SIGHUP（配置重载）、syscall.SIGUSR1（手动 dump） - 绝对不要写：
syscall.SIGKILL（信号 9），它不可捕获，写了也白写 - 避免
signal.Notify(sigChan)不带参数——默认监听所有可捕获信号，语义模糊，可能引入干扰项
收到信号后怎么安全退出
不能在 signal handler 里直接调 os.Exit：它绕过 defer、不关闭 listener、不 flush 日志、还可能 panic “send on closed channel”。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：用
context.WithCancel控制主业务生命周期，收到信号后cancel()，再等sync.WaitGroup或srv.Shutdown()完成 -
http.Server.Shutdown需配超时（如 25s），否则卡住；真正拖慢 shutdown 的，常是中间件里漏掉ctx.Done()判断的 goroutine - 通道缓冲必须设为 1：
make(chan os.Signal, 1)。设更大容易掩盖设计缺陷（比如 goroutine 挂了没人读，信号越积越多） - 别依赖
sig.String()判断类型——不同系统输出格式不一致；用switch sig.(type)或直接比较sig == syscall.SIGTERM
信号是否抵达进程，和代码无关时最多；先用 strace -e trace=rt_sigprocmask,rt_sigaction -p $(pidof yourapp) 确认信号有没有被内核投递进来，再查 Go 层逻辑。
