Go os/signal.NotifyContext 如何让服务响应退出：取消传播与信号通道边界

服务进程收到 SIGINT 或 SIGTERM 时，直接让主函数返回往往来不及关闭 HTTP 连接、刷完队列或保存最后一批状态。Go 标准库里的 os/signal.NotifyContext 可以把信号转成一个可监听的 context.Context，让各层业务沿着同一条取消链路停止。

NotifyContext 负责把信号和父上下文合并到 ctx.Done()，stop 负责解除信号接收并释放关联资源；它不会等待业务 goroutine 自己结束，收尾等待仍要由服务代码完成。

一个退出现场：信号到了，业务却还在跑

假设服务有一个持续消费任务。进程收到 SIGTERM 后，主函数如果只是调用 os.Exit，defer 不会按预期完成；如果只关闭一个共享 channel，又可能让其他 goroutine 在半关闭状态下继续写入。更稳妥的边界是：由根上下文表达“不要再开始新的工作”，由各个任务自行观察 Done 并返回。

func main() {
    parent := context.Background()
    ctx, stop := signal.NotifyContext(parent, os.Interrupt, syscall.SIGTERM)
    defer stop()

    if err := run(ctx); err != nil {
        log.Fatal(err)
    }
}

func run(ctx context.Context) error {
    for {
        select {
        case 

这里的 defer stop() 是兜底释放，不代表它会替你等待 run。如果 run 内部还有并发任务，应该在返回前显式等待任务组结束，并把等待超时设计成另一层策略。

NotifyContext 到底合并了哪些取消来源

官方源码把 NotifyContext 建立在带取消原因的派生上下文之上，然后创建容量为 1 的信号 channel，调用 signal.Notify 注册信号。内部 goroutine 在信号到来和上下文结束之间做选择。

ctx, stop := signal.NotifyContext(parent, os.Interrupt)
defer stop()

select {
case 

因此，下面三件事都可能先发生：注册的信号到达、parent.Done() 关闭、调用返回的 stop。它们最终都能让 ctx.Done() 进入关闭状态，但 context.Cause 只有在信号触发取消时才会保留描述信号的原因；主动 stop 通常对应普通取消。

stop 不是等待器：退出顺序要自己安排

stop 的职责是取消派生上下文并调用 signal.Stop，解除对信号 channel 的注册。它不会等待正在执行的业务函数，也不会自动关闭数据库、HTTP listener 或任务队列。

一个实际的收尾顺序通常是：

1. 让 ctx.Done() 通知接收循环停止拉取新任务。
2. 等待已经取出的任务结束，必要时使用带超时的子上下文。
3. 关闭 listener、数据库连接等由服务拥有的资源。
4. 调用 stop，让信号处理注册及时撤销。

如果服务只写了第一步就直接返回，文章里的“优雅退出”其实没有成立；如果一直不调用 stop，进程短时间内可能看不出问题，但信号仍会被转发到该上下文的 channel，长期运行的测试和嵌入式进程会留下不必要的注册关系。

用一次自发信号验证取消原因

在 Unix-like 系统上，可以让测试进程给自己发送 os.Interrupt，验证业务是否从 ctx.Done() 分支退出。下面的代码只演示信号与上下文的关系，实际服务不要用它替代完整的关闭编排。

func waitSignal() error {
    ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt)
    defer stop()

    p, err := os.FindProcess(os.Getpid())
    if err != nil {
        return err
    }
    if err := p.Signal(os.Interrupt); err != nil {
        return err
    }

    

验收时至少记录三项：是否从 ctx.Done() 分支返回、ctx.Err() 是否非空、context.Cause(ctx) 是否包含信号原因。不要用固定 sleep 等待“应该已经收到信号”，直接等待上下文完成更可靠。

常见问题：信号退出的几个边界

调用 stop 后，业务会立刻停止吗？

不会。它只取消上下文并解除信号注册；业务函数必须监听 ctx.Done()，已经运行的函数还要自行返回。

父上下文取消后还需要 stop 吗？

需要。父上下文结束会让派生上下文结束，但显式调用 stop 能及时释放信号注册，通常用 defer 兜底。

可以把 signal channel 直接暴露给业务层吗？

可以，但会让每个调用方都处理信号语义。服务内部更适合只传递 context.Context，由根层负责注册和收尾，业务层只关心取消。

最后检查一遍退出链路

先确认信号注册在进程入口完成，再确认所有长任务都能观察 ctx.Done()。收到信号后要有可见的“停止接新任务、等待存量任务、释放资源”顺序；最后保留 ctx.Err() 和 context.Cause(ctx)，它们比一条模糊的“服务已退出”日志更能说明取消从哪里开始。