Go语言中优雅捕获与处理系统信号的方法

首先明确几个核心要点：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() 时程序就可能卡住不动。