先说几个核心判断：signal.Notify这个函数在Go里面看起来简单，但用起来坑不少。通道类型、缓冲大小、阻塞模式、退出时机——每一步操作不当都会让你的优雅退出变成空中楼阁。
必须用 os.Signal 类型通道，容量至少为1
你如果图省事直接传个 chan int 或 chan string 进去会怎样？立刻 panic。因为 signal.Notify 对通道元素的类型有硬性要求——必须是 os.Signal。常见新手错误是随手写个 make(chan int, 1)，结果运行时抛出一行 panic: signal: unsupported channel type，调试起来还挺懵的。
正确姿势是这样：
sigChan := make(chan os.Signal, 1) signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)
这里有几个要点值得注意：
- 通道容量至少得是1，否则在极短的时间窗口内（比如主 goroutine 还没执行到
<-sigChan语句时），第一个信号就可能直接丢失。 - 多个信号可以一次性注册，不需要反复调用
Notify，代码看起来也更清爽。 - 如果你需要监听所有可捕获信号（生产环境不推荐这么干），最好显式列出
os.Interrupt、syscall.SIGTERM这些，而不是偷懒。特别要记住：os.Kill和syscall.SIGKILL在 Go 里是永远捕获不到的，这是操作系统层面的限制。
阻塞等待别卡主线程，务必配合 goroutine + select
如果在 main() 里直接写一行 <-sigChan，那程序就彻底停在这儿了。这时候其他逻辑——比如 HTTP server 启动、定时任务初始化——根本排不上队。
业界更推荐的做法是开一个 goroutine 专门监听：
go func() {
sig := <-sigChan
log.Printf("received signal: %v", sig)
// 执行清理、关闭资源等
shutdown()
os.Exit(0)
}()
// 启动服务、启动协程、初始化……
http.ListenAndServe(":8080", nil)
- 必须用
go func()把监听逻辑扔出去，否则主 goroutine 还是会被卡住。 - 收到信号后，建议显式调用
os.Exit(0)来结束进程。别指望靠所有 goroutine 自然退出来收尾——残留的 goroutine 很容易让你的进程 hang 在那边。 - 信号处理函数本身不要做耗时操作，比如同步磁盘写入或者远程调用。正确做法是发个通知给主逻辑，或者用带超时的 context 来做控制。
优雅退出的关键：让组件「可中断」且有「超时兜底」
很多人以为优雅退出就是停止 signal.Notify 或者关掉信号通道——其实远不止这些。真正需要优雅退出的是你正在跑的服务、数据库连接、长轮询 goroutine 这些活跃组件。这些组件本身得支持中断。
以 HTTP server 为例，官方从 Go 1.8 开始就提供了标准做法，配合 context 使用：
srv := &http.Server{Addr: ":8080", Handler: handler}
go func() {
if err := srv.ListenAndServe(); err != http.ErrServerClosed {
log.Fatal(err)
}
}()
<-sigChan
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
srv.Shutdown(ctx) // 等待活跃请求完成，超时则强制结束
srv.Shutdown()是标准方案，超时控制通过context实现，比手写定时器优雅得多。- 自定义 goroutine 要监听
ctx.Done()，而不是依赖全局变量或者无条件的 for 循环。 - 数据库连接池、Redis client 这类第三方库，通常都提供了
Close()或Shutdown()方法，记得去翻文档，一个一个都关掉。
测试信号处理逻辑：别真发 kill，用 syscall.Kill + os.FindProcess
本地调试时手动 kill -TERM $(pidof myapp) 不仅效率低，还很难写成自动化脚本。单元测试里更不能依赖外部进程来控制。
一个可靠的做法是在测试内部模拟信号：
func TestSignalHandling(t *testing.T) {
sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, syscall.SIGTERM)
done := make(chan bool)
go func() {
<-sigChan
done <- true
}()
// 向自己发 SIGTERM
proc, _ := os.FindProcess(os.Getpid())
proc.Signal(syscall.SIGTERM)
select {
case <-done:
case <-time.After(2 * time.Second):
t.Fatal("timeout waiting for signal")
}
}
os.FindProcess(os.Getpid()).Signal()是测试环境里唯一可控的信号触发方式。- 别用
exec.Command("kill", ...)来做这件事，跨平台兼容差不说，还可能误杀其他进程。 - Windows 上对部分信号支持有限，比如
SIGUSR1就不可用。测试时优先使用SIGINT或SIGTERM。
信号处理的逻辑本身并不复杂，真正的难点在于让整个程序的生命周期和信号对齐——每一个活跃组件都得响应中断，每一条退出路径都要有超时兜底。漏掉一个 goroutine 或者一个未关闭的连接，等你调用 os.Exit() 的时候，程序就可能卡着不动了。
