Go os/signal停止通知并避免 goroutine 泄漏的收尾方法

Go 服务退出时，真正容易留下的不是主函数，而是仍在等待 channel、ticker 或下游 I/O 的 goroutine。比较稳妥的收尾方式是：用 signal.NotifyContext 把停止信号变成共享取消信号，让每个后台任务监听 ctx.Done()，等待它们结束后再调用 stop 释放信号注册。

先取消工作，再等待资源收尾，最后解除通知注册；不要关闭由 os/signal 写入的通知 channel，也不要把退出主函数当成所有 goroutine 已退出。

官方资料：https://pkg.go.dev/os/signal

先把停止信号变成共享取消入口

NotifyContext 返回一个新的 context 和一个 stop 函数。收到 SIGINT、SIGTERM 等信号时，派生 context 的 Done 会关闭；调用 stop 则会解除信号行为并释放关联资源。这个入口适合放在服务生命周期的最外层。

package main

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

func main() {
    // 将系统停止信号统一转换成 context 取消通知。
    ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
    defer stop() // 主流程结束后解除信号注册，释放 NotifyContext 的资源。

    var wg sync.WaitGroup
    wg.Add(1)
    go worker(ctx, &wg)

    

示例中的关键不是 WaitGroup 本身，而是所有后台任务都共享同一个取消入口。只在 main 中接收信号、却不把 context 继续向下传，仍然会留下无法感知退出的工作协程。

让每个 goroutine 都有明确的退出分支

后台函数至少要有一条 ctx.Done() 分支，并在这条分支里释放自己创建的资源。对网络请求、数据库查询或队列消费，还要把同一个 context 传给下游 API；否则外层已经取消，底层仍可能阻塞。

如果某个任务必须完成最后一次写入，可以在取消分支中使用一个有上限的收尾 context，而不是无限等待。这样既保留了落盘机会，也能让部署系统在超时后接管。

区分 stop、signal.Stop 与关闭 channel

使用 NotifyContext 时，优先调用返回的 stop。它对应这次 context 注册的生命周期。手工使用 signal.Notify 时，应使用 signal.Stop(ch) 解除向指定 channel 的投递；官方保证 Stop 返回后不会再向该 channel 发送信号。

func listenManually(done 

通知 channel 的所有权仍属于创建者。若不再需要它，可以由创建者关闭，但更常见的做法是让接收循环返回、调用 signal.Stop，不把“关闭 channel”当作停止 signal 包的方式。尤其不能关闭一个仍可能被 Notify 使用的 channel，否则发送路径可能触发 panic。

二次信号与异常退出怎么处理

第一信号应进入优雅收尾：取消 context、停止接收新任务、等待已有 goroutine 退出。如果清理阶段还要识别第二次信号，可以单独再注册一个小缓冲 channel，并在第二次信号到来时记录“强制退出请求”。不要在信号处理分支中直接执行大量清理，也不要依赖最终的 defer 覆盖所有异步工作。

上线前可以按这份清单检查：每个 goroutine 是否监听 ctx.Done()；每个 ticker、timer、连接是否由创建者关闭；是否等待 WaitGroup；手工 Notify 是否匹配 signal.Stop；是否把通知 channel 错当成业务结果 channel 关闭。

相关问题

为什么调用 stop 不能代替 WaitGroup？

stop 负责解除信号行为和取消相关 context，不负责等待业务 goroutine 退出。仍然需要让工作函数响应 Done，再由 WaitGroup 划定清理完成边界。

signal.Notify 的 channel 需要多大缓冲？

只接收一种信号时，缓冲 1 通常足够；如果业务需要承接多种信号或多个独立来源，应按实际通知策略设计。缓冲大小不能替代及时接收和正确解绑。

把信号处理看成一条生命周期边界，就不容易把“收到信号”“取消工作”“资源已关闭”和“进程已退出”混成一个事件。Go os/signal 的收尾代码也因此更容易测试和复查。