Go 怎样用 signal.NotifyContext 管理退出信号

我在给一个常驻 Go 服务补退出流程时，最初把信号接收、关闭 worker 和记录退出原因写在了三个 goroutine 里。代码能跑，但一旦出现父 context 提前取消，几条路径就容易各自收尾。更稳定的做法是用 signal.NotifyContext 把操作系统信号转换成一个派生 context，再让服务统一监听 ctx.Done()。

官方文档：https://pkg.go.dev/os/signal

把 context.Background() 或上层请求 context 作为 parent，调用 signal.NotifyContext(parent, os.Interrupt, syscall.SIGTERM)；信号到达、parent 结束或主动调用 stop() 时，派生 context 都会结束。创建后立即 defer stop()，业务清理完成后让退出分支自然返回。

先把退出信号收敛到一个 context

NotifyContext 返回一个新的 context 和一个取消函数。它不是把信号值直接交给业务，而是把信号到达变成 Done() 关闭事件，因此主循环、数据库写入、消息消费和 HTTP 服务可以共享同一条退出通知。

一个最小的服务骨架如下：

package main

import (
    "context"
    "fmt"
    "os"
    "os/signal"
    "syscall"
    "time"
)

func main() {
    // 把 Ctrl+C 和常见的服务终止信号接到同一个退出上下文。
    ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
    // stop 会解除信号接管并释放相关资源，创建成功后就应该登记。
    defer stop()

    // 主循环只关心 context 是否结束，不需要再维护一个信号 channel。
    if err := run(ctx); err != nil {
        fmt.Println("服务退出：", err)
    }
}

func run(ctx context.Context) error {
    ticker := time.NewTicker(time.Second)
    // ticker 不再使用时要停止，避免退出路径留下定时器资源。
    defer ticker.Stop()

    for {
        select {
        case 

这里的关键不是把所有代码都塞进 run，而是让“退出原因”有一个共同传播入口。新增 worker 时，可以继续把同一个 ctx 传下去，避免为每个组件重复注册信号。

为什么要立即 defer stop

我第一次改造时只监听了 ctx.Done()，忘记调用返回的 stop。短时间运行看不出问题，但这个函数如果被嵌入测试、重启循环或多次初始化流程，信号处理关系就不应该一直保留。官方说明中，stop 会取消信号行为并释放关联资源；它和业务的退出错误不是一回事。

更稳妥的顺序是“创建成功后立即登记，真正完成清理后让函数返回”：这能覆盖正常返回、父 context 提前结束和运行中收到信号三种路径。不要把 defer stop() 放到某个很晚才执行的分支里，否则中途返回时可能没有释放。

• ctx.Done()：业务观察退出时机。
• ctx.Err()：判断是否是取消或超时类结束。
• stop()：解除信号接管、释放 NotifyContext 自己的资源。

三条结束路径，代码应该怎样分工

这三条路径最终都可以汇合到 ctx.Done()，但含义不同。信号到达通常意味着服务编排器或操作者要求退出；parent 先结束可能来自测试超时、上层任务取消或另一个生命周期控制器；主动调用 stop() 则是程序已经不再需要接管信号。

如果需要把信号原因写进日志，可以使用 context.Cause 查看取消原因，但业务仍应优先保证清理动作幂等：

func waitForShutdown(ctx context.Context, cleanup func() error) error {
    

不要把“收到 SIGTERM”直接等同于“所有请求已经完成”。它只表示退出信号已让 context 结束；HTTP server、worker 和数据库连接仍要在自己的关闭逻辑中设置超时，并把清理错误返回或记录下来。

os.Interrupt、SIGTERM 和 os.Kill 不是一组等价选项

本地终端按下 Ctrl+C 通常对应 os.Interrupt，服务编排环境经常通过 SIGTERM 请求进程优雅退出。把两者同时传入通常更贴近服务场景，但应根据目标平台选择可用信号。Go 文档还特别说明，os.Kill 不能被捕获或延迟处理，因此不能把它当成优雅退出信号配置进去。

Windows 对 os.Interrupt 有自己的控制台行为，Unix 系统则有更多 POSIX 信号。Go 示例中的 syscall.SIGTERM 适合 Unix 风格部署；如果代码需要跨平台编译，应把平台差异放在构建标签或平台文件中，不要假定所有信号常量和语义都一致。

我的取舍：什么时候用 NotifyContext，什么时候保留 Notify

如果需求只是“信号到达后让服务停止”，我会优先选择 NotifyContext：它和已有的 context 取消模型一致，主循环只需要一个 select 分支。只有在确实要读取信号值、区分多次信号或实现自定义信号队列时，才保留 signal.Notify 和 channel；这时要自己负责 channel 缓冲与 signal.Stop。

常见问题

调用 NotifyContext 后还需要 signal.Notify 吗？

只为驱动统一退出时通常不需要。重复注册会让退出关系更难追踪；只有业务确实要接收具体信号值时，才考虑额外使用 Notify。

stop 应该什么时候调用？

创建成功后立即用 defer stop() 登记；当业务清理结束、函数即将返回时由 defer 执行。不要为了“再次等待信号”而长期保留已经结束的信号接管。

ctx.Done 关闭后服务会自动退出吗？

不会。它只提供取消通知，主循环、HTTP 服务和 worker 必须各自监听并执行关闭逻辑，最后由主函数返回或显式结束进程。

能否用 os.Kill 做优雅退出？

不能依赖它完成清理。应让部署系统先发送可处理的终止信号，预留清理时间，超时后再使用强制终止作为兜底。