Go signal.NotifyContext 使用后为什么还要调用 stop

我在给 Go 服务补优雅退出时，最初以为 返回后程序很快就结束，stop 只是一个可有可无的收尾函数。实际边界不是这样：signal.NotifyContext 让信号暂时改为“取消 context”，而返回的 stop 负责把这层信号接管撤掉，并释放相关资源。服务退出时应该保留 defer stop() 兜底；如果清理提前完成，则应尽快显式调用一次 stop()。

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

stop 不只是让 ctx 结束

NotifyContext 返回的是 parent 的派生 context。它会在指定信号到达、返回的 stop 被调用，或 parent 自己结束时关闭 Done。这三个入口都能让业务停止等待，但它们并不代表相同的清理动作。

官方实现先创建带取消原因的 context，再建立信号通道并注册到 os/signal。信号到达时，内部 goroutine 负责取消 context；signalCtx.stop 则会取消 context，并调用 signal.Stop 停止转交信号。因此，收到信号后看到 ctx.Err()，只证明业务收到了退出通知，不能把它当成注册已经撤销。

为什么第二次 Ctrl+C 的行为可能不同

调用 NotifyContext(parent, os.Interrupt) 后，os.Interrupt 的默认行为会被改成取消返回的 context。官方文档特别说明：在 stop 调用前，后续中断不会触发默认的退出行为。这个差异正是优雅退出与强制退出之间的责任边界。

如果服务收到第一次中断后仍在等待慢任务，而代码既没有完成清理，也没有释放信号接管，第二次中断未必像用户直觉那样立即结束进程。生产代码可以把“等待清理”和“强制退出”设计成明确策略，但不要把未调用 stop 当作强制退出开关。是否退出、何时退出，仍应由主流程控制。

func run(ctx context.Context) error {
	// 业务函数只关心取消信号，不负责拥有根信号注册。
	select {
	case 

stop 应该放在哪里

最稳妥的责任划分是：创建 NotifyContext 的函数拥有 stop，创建后立刻用 defer stop() 兜底；当优雅退出已经完成时，再在那个分支显式调用一次。CancelFunc 可以重复调用，所以这种“显式提前释放 + defer 兜底”是安全的，也能让代码在新增返回路径后不容易漏清理。

func main() {
	ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
	defer stop() // 兜底：任何 return 路径都释放信号接管。

	if err := serve(ctx); err != nil {
		log.Print(err)
	}
	// serve 已经完成收尾，尽快停止继续转交信号。
	stop()
}

这里的 stop 不负责关闭监听器、等待 worker 或提交最后一笔数据；这些是 serve 或专门的 shutdown 函数的工作。它只处理 NotifyContext 这一层的生命周期。短生命周期测试也应在每次创建 context 后安排 defer stop()，避免测试之间共享一个仍然接管信号的全局状态。

延伸问答

只写 defer stop 可以吗

通常可以保证最终清理，但如果中间还有较长的收尾阶段，显式提前调用能更早停止信号转交。两者可以同时存在，重复调用不会产生第二份清理。

ctx.Done 返回后还需要检查 stop 吗

需要。Done 是业务取消通知，stop 是信号上下文的清理入口；不要用前者推断后者已经执行。

stop 会关闭整个 Go 进程吗

不会。它取消派生 context、停止该 context 接收信号，并可能恢复信号默认行为；进程是否退出由主函数和其他代码决定。

把 stop 交给 worker 调用合适吗

不推荐。拥有 NotifyContext 的主流程最清楚清理完成时机，worker 只应响应 context；把 stop 分散到 worker 容易造成责任不明和过早注销。