如何在 Go语言 中优雅地捕获并处理系统信号（Signal）

先说几个核心判断：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() 的时候，程序就可能卡着不动了。