首先明确几个核心要点：Go 语言中的 signal.Notify 函数虽然表面上简单，实际使用中却暗藏不少陷阱。通道类型、缓冲区大小、阻塞模式以及退出时机——任何一个环节处理不当，都会让所谓的“优雅退出”变成纸上谈兵。
必须使用 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 服务器启动、定时任务初始化——都无法执行。
业界更推荐的做法是启动一个专门的 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 很容易导致进程挂起。 - 信号处理函数本身不应执行耗时操作，比如同步磁盘写入或远程调用。正确做法是向主逻辑发送通知，或使用带超时的 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() 时程序就可能卡住不动。
