Go signal.NotifyContext 取消后为什么还要 Stop：信号订阅的生命周期

服务收到 Ctrl+C 后，业务 goroutine 已经从 ctx.Done() 退出，但下一次启动时信号行为变得奇怪，通常不是上下文没有取消，而是信号订阅还没有收尾。signal.NotifyContext 返回的 stop 同时承担了取消这个上下文和解除信号转发的职责，不能把它当成可有可无的清理函数。

把 stop 放进创建上下文后的清理路径；收到信号后先让业务退出，再尽快调用 stop。这样既能释放订阅资源，也能恢复后续信号的默认行为。

先把“取消上下文”和“停止订阅”拆开

signal.NotifyContext(parent, os.Interrupt) 返回两个值：派生上下文 ctx 和清理函数 stop。当 os.Interrupt 到达时，ctx.Done() 会关闭，等待这个通道的工作可以开始退出；但信号包仍然需要知道这份订阅何时结束。

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

go serve(ctx)

这里的 defer stop() 是兜底，保证提前返回时也会清理。生产服务通常还会在确认关键工作完成后显式调用一次 stop，让生命周期边界更清楚。重复调用清理函数不会改变“只处理一篇退出流程”的设计意图，但不要把它当作替代退出顺序的理由。

收到信号后，实际发生了哪几步

官方实现先通过 context.WithCancelCause 创建派生上下文，再建立内部信号通道并调用 Notify。内部 goroutine 在信号到达时调用取消函数；如果上下文先被父级取消，它则从 c.Done() 分支结束等待。

因此，业务代码看到的是 ctx.Done()，而信号包内部维护的是一份独立的订阅关系。二者的共同触发点是取消流程，但不是同一个状态变量。

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

上面的 run 只关心业务何时停止。它不应该偷偷承担信号订阅的所有权；创建 NotifyContext 的那一层才知道何时调用 stop。

为什么 stop 会影响下一次信号行为

对 os.Interrupt 来说，调用 NotifyContext 后，Ctrl+C 会先让返回的上下文取消，而不是立即沿用 Go 程序的默认退出行为。stop 会解除这份信号行为；在实现层面，它会调用 signal.Stop 结束转发，之后再次收到中断信号时，default 处理逻辑才可能重新生效。

这正是服务管理器和本地开发中容易被忽略的边界：如果一个长生命周期测试不断创建新的 NotifyContext，却从不调用 stop，旧订阅会持续存在，排查时看到的信号结果就不再只由当前测试决定。

一段可复用的优雅退出骨架

退出流程可以分成三个检查点：信号抵达后关闭业务入口，等待正在处理的工作完成，最后结束信号订阅。不要在 ctx.Done() 一关闭就立刻终止所有清理，否则数据库连接、监听器或正在写出的日志可能还没有收尾。

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

	serverDone := make(chan struct{})
	go func() {
		serve(ctx)
		close(serverDone)
	}()

	

这个骨架里，serve 通过 ctx.Done() 感知退出，closeIngress 阻止新任务进入，serverDone 表示已有任务完成，最后的 stop 收回信号订阅。具体项目如果还要响应超时，可以在父上下文上叠加 deadline，但不要因此省略订阅清理。

相关问答：测试和排查时最容易混淆的三个点

父上下文取消了，为什么还要 stop？

父上下文取消只会让派生上下文结束等待；创建的信号订阅仍有自己的资源边界。调用 stop 才是对这份订阅的明确收尾。

收到信号后能不能马上 stop？

可以，但要看业务是否还需要接收后续信号。更稳妥的做法是先拒绝新任务、等待关键清理完成，再停止订阅；如果程序准备立即退出，也应保留 defer stop() 作为异常路径兜底。

为什么测试里偶尔看不到默认退出行为？

测试可能仍保留上一轮的信号订阅，或者在信号到达后没有调用 stop。每个测试创建的上下文都应拥有清晰的所有权，结束时释放；涉及真实进程信号时还要隔离测试进程，避免影响测试运行器。

把生命周期检查写进代码审查

看到 signal.NotifyContext 时，先沿着返回值查三个问题：stop 是否被保存，业务退出是否确实监听了 ctx.Done()，以及停止订阅的时机是否晚于关键清理但早于函数返回。只回答“上下文会取消”还不够，那只覆盖了退出链的一半。

官方文档还特别说明，stop 会释放关联资源；把它当作创建订阅后的配对操作，服务重启、单元测试和命令行程序都会更容易预测。

参考：os/signal 包文档、Go 标准库 signal.go、NotifyContext 官方示例。