Go 信号处理退出偶发丢失怎么办

Go 程序收到退出信号后偶尔没有进入清理逻辑，先不要急着把原因归结为“系统信号丢了”。更常见的情况是：signal.NotifyContext 注册得太晚、监听的 context 没有被真正观察，或者辅助函数提前调用了返回的 stop。这三种问题都会让现象看起来像退出信号不稳定。

官方资料：https://pkg.go.dev/os/signal#NotifyContext、https://pkg.go.dev/os/signal#Stop

稳定的写法是把 NotifyContext 放在程序生命周期入口，使用它返回的 context 贯穿工作函数；收到取消后先完成可控收尾，再调用 stop 解除信号接管。不要在 worker 内部或初始化 helper 返回时提前清理。

先把“信号丢失”拆成四层现象

NotifyContext 返回的子 context 会在三种情况中结束：指定信号到达、返回的 stop 被调用，或者父 context 先结束。它并不是一个可以无限积压每一次信号的消息队列，也不会替你决定业务收尾是否完成。

把 NotifyContext 放在生命周期入口

不要让每个 worker 都创建自己的信号监听。程序通常只需要一个根退出上下文，再把它传给 HTTP 服务、消费循环或后台任务。这样能避免多个监听点各自做一半清理，也方便判断到底是谁负责结束进程。

package main

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

func main() {
    // 在启动长期任务之前建立统一的信号退出入口。
    ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)

    // stop 负责解除信号接管；真正的调用位置会在收尾完成后明确执行。
    defer stop()

    if err := run(ctx); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

func run(ctx context.Context) error {
    // 业务函数只依赖 context，不再自行注册操作系统信号。
    for {
        select {
        case 

这段结构的关键不是把 defer stop() 写上就结束，而是明确 stop 的所有权。main 可以用 defer 兜底，确保异常返回时释放资源；如果程序在收到信号后还要完成多步收尾，也可以在收尾完成的明确位置调用一次 stop()，让资源尽早释放。

检查 stop 有没有被调用得太早

返回的 stop 是一个取消函数，不是“收到信号后自动调用的回调”。调用它会让该 context 结束，同时解除对相关信号的接管。官方文档还特别说明，stop 可能恢复指定信号的默认行为；例如 os.Interrupt 的默认行为通常是退出进程。

下面这种封装容易制造偶发问题：helper 返回时执行了 defer stop()，但它返回后主流程才开始等待或启动真正的工作。此时 context 已经被取消，后续信号也不再按预期交给这个监听点。

func newRuntime() (context.Context, error) {
    ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt)
    defer stop() // 错误示范：函数返回后，调用方拿到的 ctx 已经结束。
    return ctx, nil
}

func newRuntimeCorrect(parent context.Context) (context.Context, context.CancelFunc) {
    // 把 stop 的生命周期交给创建者，由创建者决定收尾何时结束。
    return signal.NotifyContext(parent, os.Interrupt)
}

如果必须封装初始化，返回值应同时包含 context 和取消函数，或者让上层传入一个已经建立的 context。不要只返回 context 而把 stop 藏在局部函数里；那样调用方无法判断清理何时发生。

收到第一轮信号后怎样完成可控收尾

第一轮信号让 ctx.Done() 关闭后，业务代码还需要主动停止接收新任务，并让正在执行的操作拿到同一个 context。若某个调用完全不读取 ctx.Done()，它不会因为上层 context 结束而自动返回，这时应补充超时、关闭方法或可取消 API。

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

这里的 stop 不应被当成 cleanup 的替代品。cleanup 负责关闭监听器、停止任务和保存状态；stop 负责解除 signal 包的接管。两者职责不同，先后关系应由程序生命周期决定，而不是由某个短小 helper 的 defer 顺手决定。

为什么测试里会感觉“偶发丢失”

第一种情况是注册窗口：程序还没有执行到 NotifyContext，就已经收到信号。第二种情况是观察窗口：context 已经结束，但测试同时准备了其他可执行 case，select 并不适合表达“取消一定优先”。第三种情况是清理窗口：第一轮信号触发后，代码过早调用 stop，第二轮信号恢复了默认行为，表现为程序突然退出。

排查时可以把状态拆成三个可观察字段：是否完成监听初始化、是否进入取消分支、是否完成 cleanup。不要只打印一句“收到信号”，否则无法区分信号未到、context 未传递和 cleanup 阻塞。

type ShutdownState struct {
    registered bool
    canceled   bool
    cleaned    bool
}

func runWithState(ctx context.Context, state *ShutdownState) error {
    // 记录进入业务循环的时刻，用来排除“尚未注册就发送信号”。
    state.registered = true

    

如果需要知道是哪个信号造成取消，可以在确认 context 已由信号结束后读取 context.Cause(ctx)。不过不要用它代替清理状态；原因信息和资源生命周期是两件事。

发布前按四个检查点反向确认

1. 注册点：NotifyContext 是否在启动长期任务前创建，是否只由一个生命周期入口负责。
2. 传播点：所有需要退出的 worker、服务器和阻塞操作，是否拿到了同一个 context，是否真正读取 Done。
3. 清理点：是否先完成停止接收、等待和资源关闭，再调用 stop；是否避免 helper 返回时提前 defer。
4. 第二轮信号：是否明确知道调用 stop 后可能恢复默认行为，是否把它当作生命周期结束而不是普通状态切换。

最后可以这样判断：如果 ctx.Done() 已经结束，说明 NotifyContext 的取消传播发生了；如果业务仍不退出，应继续查 worker 的阻塞点和 cleanup，而不是重复注册信号。只有注册窗口、传播链路和 stop 清理时机都清楚，退出流程才不会被“偶发丢失”的表象带偏。

相关问题

NotifyContext 收到信号后还要手动 signal.Stop 吗？通常不需要。它返回的 stop 就是对应的清理入口；signal.Stop 用于显式 signal.Notify 注册的 channel。

为什么调用 stop 后第二次 Ctrl+C 直接退出？因为 stop 会解除接管，指定信号可能恢复默认行为。它应在收尾完成或不再需要接收信号时调用。

只在 main 里 defer stop 可以吗？可以作为兜底，但如果收尾流程较长，建议在收尾完成后显式调用，并保留 defer 防止异常路径泄漏。