Go NotifyContext 取消后为什么还会收到一次信号

如果代码同时监听了 ctx.Done() 和一个由 signal.Notify 创建的信号通道，常会看到这样的现象：context 已经取消，业务收尾逻辑执行了，但信号通道里又读到一次 os.Interrupt。这通常不是 NotifyContext “取消失败”，而是两个通知路径各自完成了投递。

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

先区分收到信号与 context 已取消

signal.NotifyContext(parent, os.Interrupt) 返回的 context 会在信号到达、调用 stop 或父 context 结束时变为 done。它返回的是取消语义，不是一个把原始信号值交给业务代码读取的 channel。

相反，下面的写法建立了两条独立路径：

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

raw := make(chan os.Signal, 1)
signal.Notify(raw, os.Interrupt)
defer signal.Stop(raw)

select {
case 

同一个进程信号可以被不同的注册目标分别观察。于是，看到一次 ctx.Done() 和一次 raw 读取，并不能推出系统发送了两次信号。

看懂 NotifyContext 的一次缓冲时序

Go 标准库实现为 NotifyContext 创建容量为 1 的内部信号通道，并注册信号通知。内部 goroutine 读取到信号后才调用取消函数。因此可以把时序理解为：

1. 操作系统把信号交给 Go 的信号处理路径。
2. 信号尝试进入 NotifyContext 的容量为 1 的内部通道。
3. 内部 goroutine 取出信号，并关闭返回 context 的 Done 通道。
4. 业务 goroutine 从 ctx.Done() 唤醒，开始收尾。
5. 调用 stop() 后，标准库注销这一路信号注册。

这里有两个容易混淆的点。第一，Done 关闭只表示取消状态已经发生，不会清空别的注册通道。第二，stop 是释放资源和恢复信号行为的操作，不是“撤销已经发生的信号”。如果信号已经进入另一条缓冲通道，之后仍可能被那条通道读到。

标准库对信号通知采用非阻塞发送：当目标通道没有可用缓冲时，不会因为业务不读取而阻塞信号处理。对只关心某一种信号的通道，容量 1 通常足够；这也意味着它不是可靠的事件队列，不应拿来统计每一次信号。

避免同时消费 signal.Notify 与 NotifyContext

最简单的修复是只保留一种退出入口。应用层通常只需要 context：

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

	if err := serve(ctx); err != nil {
		return err
	}
	// 中文说明：serve 返回后不再需要信号转发，defer 会注销 NotifyContext。
	return nil
}

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

如果确实需要原始信号值，例如要区分不同信号的审计日志，就不要再调用 NotifyContext，而是只注册一个带缓冲通道，然后由同一个循环负责取消派生 context。关键是不要让两套机制都承担“收到退出信号后的业务动作”。

正确调用 stop 并处理收尾竞态

推荐在创建 context 后立即安排 defer stop()，同时在已经完成工作且不再需要信号转发时尽早调用一次 stop。取消函数可重复调用，重复调用不会把已经发生的信号重新放回系统。

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

err := doWork(ctx)
if err != nil {
	// 中文说明：先让依赖 ctx 的工作结束，再释放 NotifyContext 的信号注册。
	return err
}

stop()
// 中文说明：stop 只负责取消派生 context 并注销注册，不负责清理其他 signal.Notify 通道。
return nil

若另一个 goroutine 也在监听独立的 signal.Notify 通道，它必须由自己的拥有者调用 signal.Stop(ch)，并在停止后决定是否丢弃通道中尚未处理的值。不能把 NotifyContext 返回的 stop 当成全局信号清理函数。

用最小程序观察一次取消

下面的示例只使用 NotifyContext，程序向自身发送一次中断信号，便于观察取消原因。示例依赖 Unix 信号，在 Windows 上不要把它当作可移植测试。

//go:build unix

package main

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

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

	p, err := os.FindProcess(os.Getpid())
	if err != nil {
		panic(err)
	}
	// 中文说明：向当前进程发送一次 SIGINT，模拟用户按下 Ctrl+C。
	if err := p.Signal(os.Interrupt); err != nil {
		panic(err)
	}

	

这个程序只会从 context 观察取消，不会再额外读一个原始信号通道。排查已有项目时，可按下面顺序判断：

结论

“取消后还收到一次信号”首先应理解为时序与注册范围问题：NotifyContext 用自己的容量为 1 的通道接收信号，再通过 Done 广播取消；另一个 signal.Notify 通道可能独立收到同一信号。生产代码应统一退出入口，创建后及时安排 stop，并由各自的拥有者停止独立信号通道。

常见追问

NotifyContext 会把信号值放进 ctx 吗？

不会。它通过取消 context 表达事件；需要信号值时应明确维护一条原始信号通道，并承担相应的停止与缓冲语义。

调用 stop 能清空 signal.Notify 的通道吗？

不能。它只处理当前 NotifyContext 创建的注册与资源；独立通道要由对应的 signal.Stop 和业务逻辑处理。

容量为 1 的信号通道能统计所有 Ctrl+C 吗？

不能把它当可靠队列。信号通知是非阻塞的，通道满时后续通知可能被丢弃；退出控制应设计成幂等状态，而不是依赖计数。