Go Signal Stop 与退出流程的竞态处理

Go 程序做优雅退出时，最容易误用的地方不是信号本身，而是把 signal.Stop 当成“关闭通知 channel”。正确的分工是：signal.Notify 建立信号到 channel 的转发，signal.Stop 撤销这条转发关系，context.Context 向工作协程传播取消，最后由一个退出协调器决定何时返回或强制退出。不要手动关闭传给 Notify 的 channel，也不要让每个收到信号的 goroutine 都独立执行一遍清理。

把“停止接收信号”“停止接收新工作”“等待已有工作结束”和“结束进程”拆成四个状态，竞态就会从隐式行为变成可以管理的边界。

先把四个对象的责任分开

signal.Notify(c, sigs...) 让标准库把匹配的操作系统信号转发到 c。这个 channel 是通信对象，不是由 os/signal 创建和拥有的资源，因此应用不应该为了“结束监听”去调用 close(c)。signal.Stop(c) 会撤销此前针对这个 channel 的注册；官方语义保证它返回后，c 不会再收到新的信号。

这一区别很重要：停止转发并不等于关闭 channel，也不等于进程已经退出。正在等待 的代码如果需要结束，应由 context、额外的 done channel 或退出协调器通知，而不能期待 channel 被 Stop 关闭后自动读到零值。

用缓冲 channel 接住首个信号

如果使用显式 channel，至少为只关心一次的信号准备一个长度为 1 的缓冲。这样信号到达时，接收方还没有立刻调度，也不会因为发送端不能阻塞而直接丢掉首个通知。

package main

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

func main() {
    // 缓冲 1 个信号，避免主 goroutine 尚未进入 select 时错过首个通知。
    sigCh := make(chan os.Signal, 1)
    signal.Notify(sigCh, os.Interrupt, syscall.SIGTERM)

    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()

    // 退出协调器只接收一次取消请求，工作 goroutine 统一观察 ctx.Done()。
    shutdown := func() {
        cancel()
        fmt.Println("开始停止接收新任务")
    }

    sig := 

示例里的 Stop 放在首个信号已经取出之后，表达的是“后续不再把信号送给这个 channel”。它不会关闭 channel，也不负责等待 HTTP 服务、后台任务或数据库连接完成。实际项目中，shutdown 应该调用服务的停止入口，并把同一个 context 传给需要中止的操作。

NotifyContext 适合统一取消入口

当程序的主要目标是把 SIGINT、SIGTERM 转换成 context 取消时，signal.NotifyContext 可以减少一层手工 channel 管理。它返回的 stop 不是“退出进程”函数，而是释放信号转发资源、恢复后续信号默认行为的取消函数。

func run(ctx context.Context) error {
    // 工作函数只依赖 context，不直接读取操作系统信号。
    for {
        select {
        case 

这里仍然要调用 stop()，即便它被 defer 保护。标准库文档建议在不再需要把信号导向这个 context 后尽快释放资源；如果希望收到首个信号后立即把控制权还给默认行为，可以在确认进入收尾状态时显式调用它，而不是把它混同为 os.Exit。

把重复 shutdown 关在一个协调器里

竞态通常来自两个入口同时调用清理：信号监听 goroutine 收到 SIGTERM，HTTP 服务错误处理又触发退出，或者首个和第二个信号几乎同时到达。最简单的约束是让所有入口只调用一个幂等函数，函数内部用 sync.Once 保护第一次状态切换。

type Shutdown struct {
    once sync.Once
    done chan struct{}
}

func (s *Shutdown) Begin() {
    s.once.Do(func() {
        // 只关闭内部完成通知，由 Shutdown 自己拥有这个 channel。
        close(s.done)
        // 这里执行停止接收新任务、通知服务退出等一次性动作。
    })
}

注意这个例子中的 done 是结构体自己创建并拥有的 channel，与传给 signal.Notify 的 sigCh 完全不同。前者可以在明确的所有权下关闭，后者只能通过 Stop 撤销信号转发。

为二次中断预留明确的出口

优雅退出可能需要等待请求、消息消费或文件落盘。若第二次 Ctrl+C 仍被同一个取消 context 吸收，用户会感觉程序“没有反应”。可以把退出协调器设计为两种状态：第一次信号进入 graceful shutdown，第二次信号只负责取消等待或触发强制退出。关键是不要让第二次信号重新执行一套清理。

如果使用 NotifyContext，要先决定 stop() 的调用时机：在开始清理后调用，表示不再继续把信号导向这个 context；然后由另一个受控的接收点、超时策略或进程管理器决定是否结束。若直接调用 os.Exit，延迟函数不会执行，日志和资源收尾也可能被跳过，因此它只能是明确的最后出口。

一张表检查退出边界

排查信号退出竞态的三个问题

第一，确认传给 Notify 的 channel 是否被业务代码关闭；如果被关闭，先移除这个关闭动作。第二，确认所有工作是否真正观察了 ctx.Done()，尤其是阻塞 I/O、无缓冲发送和等待外部资源的分支。第三，确认第二次信号是否有单独策略，并记录“开始收尾、收尾完成、强制结束”三个状态，而不是只打印一条收到信号的日志。

官方文档与源码入口可直接复制：https://pkg.go.dev/os/signal、https://go.dev/src/os/signal/signal.go。它们分别说明公开 API 语义和 Stop 等待信号投递静默的实现边界。

常见延伸问题

Stop 会关闭 channel 吗？不会。它撤销 Notify 注册，返回后该 channel 不再收到新的信号；channel 的关闭和退出通知需要由自己的拥有者设计。

为什么不能只用 os.Exit？因为 os.Exit 会跳过 defer，正在进行的资源释放、日志刷盘和请求收尾可能不会执行。它更适合作为超时后的最后策略。

缓冲大小必须很大吗？只处理一次 SIGINT 或 SIGTERM 时，长度为 1 通常足够；如果业务需要观察更高频率的信号，应重新评估是否真的需要逐个保留信号，以及接收方能否及时消费。

最终的判断标准很简单：Stop 只管理信号转发，context 只传播取消，只有一个退出协调器拥有 shutdown 状态；任何需要关闭的 channel 都必须由创建它的代码负责。这样即使信号和退出动作同时发生，也不会靠关闭错误的 channel 来“碰运气”。