Go signal.NotifyContext 收不到退出信号怎么办：信号注册、取消顺序与测试核对

程序收到终止信号却一直不退出，先别急着把问题归到操作系统。Go 里更常见的原因是 signal.NotifyContext 创建得太晚、父 Context 已经取消，或者测试只调用了清理函数却没有真的给进程发送信号。

signal.NotifyContext 到底替你完成了什么

signal.NotifyContext(parent, os.Interrupt, syscall.SIGTERM) 会返回一个派生 Context 和停止函数。关注的信号到达后，派生 Context 的 Done() 被关闭；它不会替你等待 HTTP 请求、关闭数据库连接，也不会自动结束主函数。

可以把它看成一条很短的传递链：操作系统信号进入 os/signal，再取消派生 Context，业务代码从 看到退出通知，最后由应用决定如何收尾。

一个不容易漏信号的最小写法

注册要发生在启动工作之前。这样工作协程拿到的就是同一个退出边界，主流程也能在等待收尾时保持可控。

package main

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

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

    workDone := make(chan struct{})
    go func() {
        defer close(workDone)
        

这里有两个等待点：主流程先等 Context 取消，再等工作协程关闭 workDone。只写第一个等待点，进程可能在资源还没释放时直接返回；只写第二个等待点，又无法表达谁负责触发退出。

为什么要保存并调用 stop

stop 不只是“取消一个 Context”的别名。它还会停止对信号的通知并释放关联资源。放在 defer 中能覆盖正常返回和提前失败两条路径；如果业务明确完成收尾，也可以在收尾确认后主动调用一次。

三种“收不到退出信号”的边界

尤其要留意父 Context。下面的写法看起来像是“先准备一个可退出 Context”，实际却把已经取消的 Context 传给了通知函数：

parent, cancel := context.WithCancel(context.Background())
cancel()
ctx, stop := signal.NotifyContext(parent, syscall.SIGTERM)
defer stop()
fmt.Println(ctx.Err()) // context canceled

这种情况下，程序等待 不会再等新的信号，因为取消已经发生。排查时先打印 ctx.Err()，比反复发送信号更快。

测试时怎样证明真的收到了信号

单元测试可以直接创建 Context 并验证取消，但这只能证明业务响应逻辑。若要覆盖注册链路，应让测试进程向自己发送一个受关注信号，再观察 Done() 是否关闭；测试结束时记得调用 stop，避免通知状态影响同一进程中的其他测试。

func TestNotifyContext(t *testing.T) {
    ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGTERM)
    defer stop()

    p, err := os.FindProcess(os.Getpid())
    if err != nil {
        t.Fatal(err)
    }
    if err := p.Signal(syscall.SIGTERM); err != nil {
        t.Fatal(err)
    }

    select {
    case 

测试环境不一定允许所有信号按生产环境的默认动作运行，因此测试只验证 Context 取消和超时，不把“进程是否退出”作为同一个测试的断言。真正的服务退出验收，再放到独立的进程级测试或部署检查中。

把信号通知接到真实服务时的收尾顺序

在 HTTP 服务中，推荐把信号 Context 作为服务生命周期的上层边界：收到取消后先停止接收新请求，再等待在途请求和后台任务在有限时间内结束，最后关闭数据库、消息连接等资源。

不要把所有事情塞进一个 select。信号只负责发出“该收尾了”的通知，具体的超时、并发等待和失败记录仍由服务代码负责。收尾成功后调用 stop()，可以避免信号通知长期留在进程里。

相关问题

signal.NotifyContext 能监听任意字符串吗？

不能。它接收的是 os.Signal，例如 os.Interrupt 或 syscall.SIGTERM。业务自定义事件应使用 Context 取消、channel 或服务内部消息表达。

只调用 stop，能模拟收到 SIGTERM 吗？

不能。调用 stop 是主动解除通知并取消关联 Context 的清理动作，不等价于操作系统把 SIGTERM 送进进程。测试两者时要分别断言。

为什么生产环境常用 SIGTERM 而不是只监听 Ctrl+C？

Ctrl+C 通常对应终端发出的中断信号，SIGTERM 更适合服务管理器请求进程有序退出。两者可以同时注册，但收尾逻辑应只有一套。

结语：先核对链路，再判断信号是否丢失

遇到“收不到退出信号”时，按父 Context、注册时机、ctx.Done() 读取点、测试是否真的发信号、stop() 清理这五项逐一核对，通常能很快定位。信号通知只是生命周期的入口，能否安全退出取决于后续收尾是否有明确的等待和超时边界。