os/signal.Notify 未收到信号时的生命周期检查

给 os/signal.Notify 注册了 SIGTERM 或 os.Interrupt，程序却一直没有进入接收分支时，先不要把问题归结为“Notify 失效”。这条链路至少有四个生命周期节点：信号是否真的发给当前进程、Notify 是否注册了同一个 channel、channel 是否有机会接收、主流程是否在信号到达前已经结束。

最稳妥的处理方式是：使用有缓冲的 chan os.Signal，让主流程或专门的 goroutine 持续等待，处理完成后调用 signal.Stop；如果业务本来就是由上下文驱动，则优先使用 signal.NotifyContext。这样可以把“没收到信号”和“生命周期已经结束”分成两个可判断的问题。

Notify 只建立信号到 channel 的投递关系，不会替你延长进程寿命，也不会保证业务代码一定消费到信号。排查时先看进程是否还活着，再看 channel、信号类型和清理时机。

先把 Notify 的注册链路对齐

官方文档把 Notify 定义为：让 os/signal 包把指定的异步信号转发到给定 channel。它接收的是“发送方向”的 channel，调用成功本身只说明注册动作完成，并不代表当前已经有信号排队。

注册和消费必须指向同一个 channel。不要在函数内部创建一个 channel 后丢失引用，也不要把一个 channel 注册给 Notify，却在另一个新 channel 上等待。最小写法如下：

package main

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

func main() {
	// 只等待一个中断信号，容量 1 可以留下接收窗口。
	signals := make(chan os.Signal, 1)
	signal.Notify(signals, os.Interrupt)
	defer signal.Stop(signals) // 生命周期结束时解除注册。

	// 这里必须从同一个 signals 接收，不能重新 make 一个 channel。
	sig := 

如果传入 nil channel，当前官方实现会直接 panic；如果不传信号参数，则表示接收所有可用的异步信号，但这并不等于所有平台都具有相同的信号集合。生产代码通常应明确列出业务真正处理的信号。

主流程提前结束时，Notify 看起来就像没有生效

一个常见误判是把注册代码放在短命 goroutine 或初始化函数里，然后让 main 很快返回。Go 进程退出后，所有 goroutine 都随进程结束，之后再发送信号自然不会有接收日志。此时问题不是信号没有投递，而是接收方和进程已经不存在。

可以把等待动作放在主流程，或者让主流程等待一个明确的退出事件。下面的例子把“收到信号”和“业务完成”都放进同一个生命周期里：

func waitForStop(workDone 

这段代码需要额外导入 syscall。更重要的是，返回 nil 不是收到“空信号”，而是业务完成的标记。用不同分支表达不同事件，才能知道下一步是优雅退出、继续服务，还是记录异常。

用自发信号把投递、消费和退出拆开

当现场环境不方便手动发送信号时，可以让进程给自己发送一个中断信号。这个例子只用于隔离排查：它验证当前进程、注册 channel 和接收循环是否处于同一生命周期，不代表所有部署环境都应采用自发信号。

package main

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

func main() {
	// 为单个信号保留一个缓冲位置，避免发送瞬间没有接收者。
	signals := make(chan os.Signal, 1)
	signal.Notify(signals, os.Interrupt)
	defer signal.Stop(signals)

	process, err := os.FindProcess(os.Getpid())
	if err != nil {
		panic(err) // 示例只关注生命周期，真实服务应返回或记录错误。
	}
	if err := process.Signal(os.Interrupt); err != nil {
		panic(err) // 发送失败说明进程或平台边界需要单独排查。
	}

	// 只有消费到 signals，才能证明 Notify 链路完成了一次闭环。
	fmt.Println("收到:", 

如果这个例子能收到信号，而部署环境收不到，优先检查发送者是否把信号发给了正确的 PID、容器是否把信号转发给应用进程，以及目标信号是否在当前平台可用。如果这个例子也收不到，再回到 channel、注册时机和主流程是否提前退出。

NotifyContext 更适合由上下文驱动的服务

如果收到信号的目标只是取消一组正在运行的任务，可以让 signal.NotifyContext 管理 channel 和取消关系。返回的 stop 既能取消上下文，也会解除信号注册；任务完成后应尽快调用它，避免信号继续被当前上下文拦截。

func runServer(parent context.Context) error {
	// 信号到达、父 context 取消或 stop 调用都会让 ctx.Done() 关闭。
	ctx, stop := signal.NotifyContext(parent, os.Interrupt, syscall.SIGTERM)
	defer stop() // 无论服务如何返回，都释放信号注册资源。

	if err := serve(ctx); err != nil {
		return err // serve 应在 ctx.Done() 关闭后停止接收新任务。
	}
	return nil
}

这种写法适合 HTTP 服务、消费者和后台任务，因为业务函数只需要关注 ctx.Done()。如果需要区分具体信号，仍可以使用显式 channel；不要为了追求统一而把所有信号都转换成同一个无来源的布尔状态。

收到信号后为什么还要检查 Stop 和 channel 缓冲

官方文档特别强调，signal 包不会阻塞向 channel 的发送；对于只关心一个信号的 channel，容量 1 通常足够。无缓冲 channel 或容量过小，会让信号在投递时没有可用位置，表现为“偶尔没收到”。这不是可靠的同步队列，应用应按预期信号速率准备缓冲。

Stop 的语义也不是关闭 channel。它解除此前对这个 channel 的所有 Notify 注册，并保证返回后不再向该 channel 投递信号。channel 仍由创建者负责管理，不能因为调用了 Stop 就从另一个 goroutine 重复关闭它。

平台差异和采用边界

os/signal 不是跨平台的同一组操作系统信号抽象。官方文档说明，Windows 主要支持 os.Interrupt 和部分终止事件，Unix-like 系统则有更多异步信号；SIGKILL 和 SIGSTOP 也不能被程序捕获。跨平台服务应把可处理信号集中在平台适配层，不要假设 Linux 上的每个名称在其他系统都存在。

另外，Notify 改变的是 Go 进程对指定信号的处理方式，不是一个通用的进程监管器。容器入口、init 进程、父进程转发、cgo handler 和部署平台的停止超时，都可能影响信号能否到达。文章中的最小例子适合定位 Go 侧生命周期问题；系统层问题要沿着实际 PID 和父子进程关系继续检查。

相关问题

为什么调用 Notify 后程序还是立刻退出？ 因为 Notify 不会阻塞主流程，也不会自动创建永久等待；必须由主流程或仍存活的 goroutine 等待 channel 或 context。

调用 Stop 会关闭通知 channel 吗？ 不会。Stop 只解除注册，channel 的创建、读取和关闭责任仍由业务代码决定，通常不需要关闭它。

一个信号可以注册多个 channel 吗？ 可以。官方语义是各 channel 独立接收副本，但每个接收方都要有自己的生命周期和清理策略。

什么时候应该改用 NotifyContext？ 当信号的业务结果主要是取消请求、停止服务或终止后台任务时，NotifyContext 能把取消和注册释放绑定在一起；需要精确区分每个信号时，再保留显式 channel。