Go os/signal接收优雅退出信号的实现步骤

Go 服务要实现优雅退出，关键不是收到信号后立刻调用 os.Exit，而是把 SIGINT 或 SIGTERM 转成一个可观察的退出触发点，再让后台任务停止接收新工作、等待已有工作收尾。标准库 os/signal 提供了这条链路：用容量为 1 的 channel 注册 signal.Notify，收到信号后进入清理逻辑；如果任务本身已经使用 context，则优先考虑 signal.NotifyContext。

先区分 SIGINT、SIGTERM 与不可捕获信号

os.Interrupt 通常对应终端里的 Ctrl+C，适合本地开发和手工停止；Unix 服务被管理器要求退出时，通常会收到 syscall.SIGTERM。这两个信号都属于异步信号，适合交给 os/signal。而 SIGKILL、SIGSTOP 不能被程序捕获，不能把优雅退出设计建立在它们之上。

标题中的“接收”只覆盖进程拿到信号并作出清理决策，不等于保证所有任务一定完成。清理动作仍要有自己的超时，外部进程也可能在等待后使用强制终止。

用缓冲 channel 注册 signal.Notify

最小写法如下。代码中的 channel 只负责传递通知，不承载业务数据；清理完成后应停止继续向它投递。

package main

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

func main() {
    // 容量为 1 可以先保存一次信号，避免接收方尚未就绪时没有槽位。
    signals := make(chan os.Signal, 1)
    // 只订阅本程序确实要处理的退出信号，避免接收无关信号。
    signal.Notify(signals, os.Interrupt, syscall.SIGTERM)

    // 阻塞等待退出通知；生产代码在这里接入服务停止和资源清理。
    received := 

Notify 不会阻塞发送，因此调用方需要给 channel 留出足够的缓冲空间。只为一个退出触发点服务时，容量 1 是标准库文档给出的实用起点。不要把无缓冲 channel 当成更“严格”的写法：接收 goroutine 尚未调度时，通知没有等待业务处理的语义。

把信号接收接入服务生命周期

真实服务收到信号后，不宜只打印一行日志就返回。通常先停止接收新请求或新任务，再等待正在执行的工作；最后关闭连接、文件、消费者和其他资源。这里可以用第二个信号作为加速退出的入口，但不要让清理函数被多个 goroutine 同时执行。

// runService 表示主服务循环；它只接收退出信号，不负责模拟业务实现。
func runService() error {
    // 这里放启动监听器、消费者或定时任务的代码。
    return nil
}

func shutdown() {
    // 按“停止新工作 -> 等待在途工作 -> 关闭资源”的顺序编排收尾动作。
}

func main() {
    signals := make(chan os.Signal, 1)
    signal.Notify(signals, os.Interrupt, syscall.SIGTERM)
    defer signal.Stop(signals)

    // 服务启动失败时直接返回，不进入信号等待分支。
    if err := runService(); err != nil {
        return
    }

    // 收到一个退出信号后只执行一次收尾路径。
    

关键边界是“谁拥有 shutdown”。如果监听、HTTP 服务和后台消费者分别有自己的退出逻辑，建议由一个主 goroutine 统一编排，子任务只响应取消，不各自关闭同一资源。这样既能避免重复关闭，也能让退出日志反映真实的阶段。

用 NotifyContext 传播取消原因

当服务已经以 context.Context 传递取消信号时，NotifyContext 更自然。它返回一个派生 context：父 context 结束、列出的信号到达或返回的 stop 被调用，任一条件满足时，派生 context 的 Done channel 会关闭。

func main() {
    // 把 Ctrl+C 和终止信号转换为统一的 context 取消事件。
    ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
    defer stop() // 释放通知资源，并在不需要时恢复默认信号行为。

    // 后台任务应把 ctx 继续传给阻塞调用，而不是另造停止 channel。
    done := make(chan struct{})
    go func() {
        defer close(done) // 无论收到取消还是正常结束，都通知主流程。
        doWork(ctx)
    }()

    // 等待任务结束；doWork 需要在 ctx.Done() 上及时返回。
    

这段示例的重点不是 goroutine 的具体业务，而是取消路径。doWork 内部要在自己的 select 中监听 ctx.Done()，并把 context 传给支持取消的下游调用。stop 应在任务不再需要信号通知后尽快调用，不能只依赖进程退出时的回收。

重复信号、Stop 与平台边界

重复信号不应触发多套并发清理流程。可以让主流程只从 channel 取一次并设置退出状态；若要实现“第一次优雅、第二次加速”，也应把第二次信号的行为写成独立分支，并确保它不会绕过关键资源的最小释放动作。

相关问题

signal.Notify 的 channel 要不要加缓冲？

要。只为一个信号通知点服务时容量 1 通常足够，因为 signal 包不会阻塞发送，缓冲能覆盖接收方尚未调度的短窗口。

调用 NotifyContext 后为什么还要 stop？

stop 会注销信号行为并释放关联资源；任务完成且不再需要信号时应主动调用，而不是把清理责任留给进程结束。

SIGKILL 能用 os/signal 接收吗？

不能。SIGKILL 和 SIGSTOP 不能被程序捕获或改变，优雅退出只能针对可交给程序处理的异步信号设计。

收到 SIGTERM 就代表所有请求已完成吗？

不代表。它只是退出通知；服务仍需停止新工作、等待在途任务，并用超时保护清理流程。