Go中无法拦截os.Exit()、panic和SIGKILL，因它们绕过defer/recover/context；唯一可响应的是SIGINT/SIGTERM，需用带缓冲channel监听并封装为可复用优雅退出模块。
Go 程序里没有“主进程突然强制退出的异常”可拦截——os.Exit()、panic、信号 kill -9（SIGKILL）这三类情况，**根本不会触发任何 defer、不会进入 recover、无法被 context 捕获**。所谓“安全拦截”，实际是指：对可响应的退出信号做前置防御，对不可响应的场景做资源冗余与兜底设计。
为什么 os.Exit() 和 SIGKILL 无法被拦截
这两者是操作系统级强制终止：os.Exit() 跳过所有函数返回路径，SIGKILL 连 signal handler 都不给机会执行。你写的 defer、recover、context.CancelFunc 全部失效。
-
os.Exit(1)一调用，整个进程立刻终止，哪怕 main 里刚 defer 了文件 close，也根本没机会执行 -
kill -9 $PID是内核直接回收资源，Go runtime 甚至收不到通知 - 试图在 goroutine 里用
recover()捕获os.Exit()？无效——它不是 panic，不走 panic 流程
真正能响应的只有 SIGINT 和 SIGTERM
这是唯一可控的入口。必须用 signal.Notify() 显式监听，且 channel 必须带缓冲：
- 错误写法：
sigCh := make(chan os.Signal)→ 无缓冲，第一次Ctrl+C可能丢信号 - 正确写法：
sigCh := make(chan os.Signal, 1)→ 至少缓冲 1 个信号，防快速连按 - 必须同时注册：
syscall.SIGINT（对应Ctrl+C）和syscall.SIGTERM（对应docker stop、systemd stop） - 别用
os.Interrupt替代syscall.SIGINT，Windows 下行为不一致
模块内如何封装可复用的优雅退出逻辑
不要在每个 main 里重复写 signal + WaitGroup + Shutdown。把核心逻辑抽成可导入的模块：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 暴露一个
Shutdown()函数，接收context.Context和超时时间（如5 * time.Second） - 内部维护一个私有
sync.WaitGroup，所有启动的 goroutine 必须wg.Add(1)+defer wg.Done() - HTTP server 关闭必须用
srv.Shutdown(ctx)，不能用srv.Close()，否则连接被硬断 - 数据库连接、日志 flush、临时文件清理等，都应在
Shutdown()中显式调用，且设超时 - 模块初始化时启动 signal 监听 goroutine，但不阻塞调用方；退出由外部主动触发
示例片段（非完整代码，仅示意结构）：
func (m *Module) Start() {
go func() {
sigCh := make(chan os.Signal, 1)
signal.Notify(sigCh, syscall.SIGINT, syscall.SIGTERM)
<-sigCh
m.Shutdown(context.WithTimeout(context.Background(), 5*time.Second))
}()
}
<p>func (m *Module) Shutdown(ctx context.Context) {
// 1. 关闭 HTTP server
if m.srv != nil {
m.srv.Shutdown(ctx)
}
// 2. 关闭 DB 连接
if m.db != nil {
m.db.Close()
}
// 3. 等待后台任务
done := make(chan struct{})
go func() { m.wg.Wait(); close(done) }()
select {
case <-done:
case <-ctx.Done():
}
}
容易被忽略的竞态点和数据残留
即使 signal + WaitGroup + Shutdown 全到位，仍可能出问题：
- 多个信号连续到达时，
sigCh缓冲区满后新信号会丢——但更危险的是：如果 shutdown 逻辑没做幂等，重复收到信号可能 panic 或 double-close - goroutine 内部用了
time.AfterFunc或time.Ticker，没在 shutdown 时Stop()，会导致 goroutine 泄漏 - log 包默认 buffer 不 flush，
Shutdown()前必须显式调log.Sync()，否则最后几条日志永远不落盘 - 临时文件、锁文件没加
defer os.Remove或没在 shutdown 里清理，重启后残留文件可能阻塞下次启动
真正的“安全”，不在于拦截所有退出，而在于让每次可响应的退出都做完该做的事，并接受不可响应场景下的数据损失边界。
