信号处理

把 Go 的信号处理从独立 channel 迁移到 Context 时，核心改动是把 signal.Notify 换成 signal.NotifyContext：信号到达后，返回的 Context 会结束，业务 goroutine 只需监听同一个 Done()。任务收尾后仍要调用返回的 stop，它负责注销信号行为并释放关联资源。

Go 官方地址：https://pkg.go.dev/os/signal#NotifyContext

本文只讨论“让一次进程信号停止当前任务”这一边界，不展开完整的 HTTP 优雅关闭、服务编排或操作系统信号清单。代码中的目录、服务名和超时值均为教学示例，不代表本文运行日志。

先看旧 Notify 写法的责任边界

旧写法通常把信号送入 channel，再由主 goroutine 转成业务状态。它没有错，但退出语义被拆散了：channel 负责接收，select 负责判断，调用方还要决定何时 signal.Stop，下游函数也无法直接拿到取消信号。

// 旧式写法：信号接收与任务取消由调用方自行拼接。
func waitSignal() {
    sigs := make(chan os.Signal, 1)
    // 缓冲 1 能避免单个信号到达时立刻阻塞运行时转发。
    signal.Notify(sigs, os.Interrupt)
    defer signal.Stop(sigs)

    // 这里只能把信号变成本地分支，不能自动传给下游函数。
    sig := 

这段代码最容易遗漏的是清理：如果业务提前完成，仍有一个信号注册关系留在进程里；如果把 channel 继续传给多个组件，又要自行约定谁读取、谁停止。升级的目标不是“信号变得更强”，而是把取消能力放进已有的 Context 链。

迁移到 NotifyContext

NotifyContext(parent, signals...) 返回两个值：派生 Context 和一个 context.CancelFunc 类型的 stop。列出的信号到达、父 Context 结束或调用 stop，三者任意一个先发生，返回 Context 的 Done() 就会关闭。

// 迁移后的入口：把进程信号转换成可向下游传播的 Context。
func runService(parent context.Context) error {
    ctx, stop := signal.NotifyContext(parent, os.Interrupt, syscall.SIGTERM)
    // 无论任务因何种原因返回，都撤销信号注册。
    defer stop()

    // 下游只依赖 Context，不需要知道信号来自哪个 channel。
    if err := runWorker(ctx); err != nil {
        return err
    }
    return nil
}

func runWorker(ctx context.Context) error {
    select {
    case 

这里的关键不是把 ctx 保存到全局，而是沿调用边界传递。任何真正可取消的下游操作都要继续使用这个 Context，例如把它传给支持 Context 的查询、请求或 worker。一个函数若完全忽略 ctx.Done()，外层取消也不会强行杀掉它。

stop 不是第二个取消原因

stop() 常被误解成“收到信号后必须调用的确认函数”。它更准确的职责是停止继续接收这些信号，并释放 NotifyContext 关联资源。官方实现会取消内部 Context，然后对内部 channel 调用 signal.Stop。

因此推荐在创建后立刻安排兜底清理，并在任务确认结束后尽早调用一次：

// 让信号只在服务仍需要时改变默认行为。
ctx, stop := signal.NotifyContext(parent, os.Interrupt)
defer stop()

err := serve(ctx)
// serve 已结束，不再需要把后续 Ctrl+C 转发给这个 Context。
stop()
return err

重复调用 stop 是安全的，但代码仍应保持一个清楚的所有权：创建 Context 的函数负责 stop，调用方不要在多个层级都把它当成公共清理入口。若收到信号后还要先完成有限的排空或保存，先等待那些操作结束，再 stop；不要在信号刚到时就把仍在使用的信号注册关系误删。

按取消来源判断结果

同一个 ctx.Done() 可能由三种原因触发。对于一般 worker，ctx.Err() 足够判断是 context.Canceled 还是 context.DeadlineExceeded；如果要知道具体哪个信号造成取消，可以使用 context.Cause(ctx)，信号触发时官方实现会设置带有信号名称的原因。

不要只比较错误字符串来决定是否报警。若业务只关心“是否应停止”，比较 ctx.Err()；若要保留根因，再用 context.Cause 配合 errors.Is 或类型判断。信号触发后的收尾结果也未必是错误，服务可以把正常退出和真正的处理失败分开记录。

版本迁移后的回归清单

NotifyContext 从 Go 1.16 起提供。迁移旧代码时，可以按下面的变更表逐项检查：

可移植性上，os.Interrupt 和 os.Kill 是 os 包保证存在的信号值，但 os.Kill 不能被捕获或忽略，不能拿它做优雅退出触发器。跨平台程序优先使用 os.Interrupt；Unix 专属的 syscall.SIGTERM 应放在平台边界清楚的代码里。

常见问题

收到一次 Ctrl+C 后为什么不再退出？

因为 NotifyContext 暂时接管了默认行为，第一次信号只会取消 Context。程序应让任务收尾并调用 stop；如果用户需要第二次中断立即退出，应另行设计“第二次信号”的策略，不要假设 NotifyContext 自动提供强制退出。

只写 defer stop 够不够？

通常够用，尤其函数返回就意味着任务生命周期结束。但如果函数内部已经确认所有下游操作完成，尽早调用 stop 能缩短信号被转发的时间；保留 defer 作为异常路径兜底。

能不能把 stop 传给 worker？

不建议。worker 需要的是取消观察权，传 ctx 即可；stop 是信号注册所有者的资源管理权。把两者混传，容易让下游提前注销仍由上层使用的信号关系。

这次迁移可以压缩成一句话：用 NotifyContext 统一取消入口，用 ctx.Done() 让工作停止，用 stop() 结束信号注册的生命周期；三者职责不同，不能互相替代。