Go os/signal 处理服务退出信号的生命周期

Go 服务用 os/signal 接收退出信号时，NotifyContext 只是发出取消通知，不会替你关闭服务、等待请求或释放业务资源。一个清晰的退出入口应在收到通知后释放信号注册，用独立的超时 Context 执行清理，再让 main 在清理结束后返回。

本文用一个本地 HTTP 服务说明这条退出路径，范围限于 NotifyContext、清理顺序和二次信号，不涉及部署平台的完整下线协议。官方文档入口：https://pkg.go.dev/os/signal；HTTP 收尾语义：https://pkg.go.dev/net/http#Server.Shutdown。

收到退出信号，为什么服务还没结束

可以先看一个典型现象：开发者按下 Ctrl+C 后，程序输出“开始退出”，却一直留在后台；或者第一次中断开始清理，第二次中断也没有结束。这不必先归因于 Go 没收到信号，而应拆成两个问题：退出通知是否到达，以及收到通知后谁负责等清理完成。

exitCtx 的 Done 关闭只说明退出条件已触发。若 goroutine 没有检查 Context，或者卡在不支持取消的外部调用，通知本身不会强行终止它。另一方面，main 如果立即返回，其他 goroutine 即使正在 Shutdown，也不会得到继续清理的保证。

因此排查时要找明确的等待对象：HTTP 服务由 Shutdown 返回表示本次收尾的结果，后台任务需要自己的完成通知。不要把“Context 已取消”“Serve 已返回”“所有业务都已收尾”当作同一个事件。

先把退出通知和清理预算分开

把 exitCtx 传给 context.WithTimeout(exitCtx, ...) 并不能重新获得几秒清理时间，因为父 Context 已经取消。示例改从 Background 创建 cleanupCtx。exitCtx 是通知边界，cleanupCtx 是收尾预算；两者各负其责。

HTTP Shutdown 使用 cleanupCtx，不把 exitCtx 设成全部请求的父 Context。这样第一次退出通知不会自动取消所有正在服务的请求。若业务目标恰好要求中断在途请求，应显式设计那个策略，而不是误把“优雅退出”写成“所有请求立刻失败”。

NotifyContext 还可能因父 Context 取消或主动调用 stop 而结束，不应仅凭 Done 就断言收到的具体信号。本文父 Context 是 Background，正常退出分支关注停止通知，不用它统计信号次数。

用主协程管理 HTTP 服务的退出

下面的独立 main.go 面向 Linux/macOS，只监听回环地址。端口 8087 需要可用；Go 版本需支持 NotifyContext。代码由读者自行运行，本文未启动服务、发送信号或记录实测日志。

package main

import (
    "context"
    "errors"
    "fmt"
    "log"
    "net"
    "net/http"
    "os"
    "os/signal"
    "syscall"
    "time"
)

func run() error {
    // 面向Linux/macOS；Windows的服务控制需要单独设计
    exitCtx, stop := signal.NotifyContext(
        context.Background(), os.Interrupt, syscall.SIGTERM,
    )
    defer stop() // 启动失败等提前返回路径也释放注册

    ln, err := net.Listen("tcp", "127.0.0.1:8087")
    if err != nil { return fmt.Errorf("listen: %w", err) }
    defer ln.Close()

    mux := http.NewServeMux()
    mux.HandleFunc("/work", func(w http.ResponseWriter, r *http.Request) {
        // 用短暂等待代表可取消请求，真实业务仍需设置自己的截止时间
        timer := time.NewTimer(250 * time.Millisecond)
        defer timer.Stop()
        select {
        case 

这里先同步建立 listener，再由 goroutine 调用 Serve，启动错误会直接返回；主协程同时关注 serveErr 和退出通知。接到通知后调用 Shutdown，并留在 run 中等待。8 秒是示例选择的清理预算，不是标准库的默认值，也不是保证每个清理动作都会在这段时间内完成。

正常收尾的预期是先出现 shutdown requested，再在 Shutdown 成功后出现 shutdown complete。若预算耗尽，代码显式调用 Close 关闭连接并返回错误；不要把这个降级路径打印成“所有工作完成”。Close 也不能强制杀死任意自定义 goroutine，业务阻塞仍须按自身的取消与超时契约处理。

清理依赖不能只靠一组 defer

实际服务可能还有任务生产者、消费者、数据库和日志输出。这时清理顺序应按依赖决定：先阻止新工作进入，等待仍需要共享资源的处理者结束，最后释放这些共享资源。例如请求处理还在用数据库时，就不能因为收到了信号而提前关闭数据库。

示例只有 HTTP 服务与 listener，不冒充实现了数据库、队列或日志刷新。扩展时可以让多个收尾动作共享同一 cleanupCtx，避免每个阶段各拿完整预算导致总时长累加；但各组件必须真正支持该 Context，单纯把参数传进去不代表等待一定有上限。

defer 适合函数返回时释放已获得的资源，却不会自动决定跨 goroutine 的结束顺序。尤其不要在业务 goroutine 中调用 log.Fatal 或 os.Exit 来触发退出：os.Exit 会立即结束进程，不执行 defer。示例让 run 返回错误，等它的 defer 执行后，main 才选择非零退出状态。

二次信号为什么不一定立即退出

NotifyContext 注册期间，后续中断可能仍被该订阅接收，而已取消的 Context 不会因第二次信号再关闭一次。只把 stop 写成 defer，意味着清理期间订阅可能一直存在；这就是“第二次 Ctrl+C 没按预想退出”的一种原因。

示例收到第一次通知后立即调用 stop，同时保留 defer stop 处理提前返回。stop 释放本次注册；在没有其他注册、忽略设置或特殊继承行为影响时，之后的 SIGINT 或 SIGTERM 可恢复通常的退出行为。这不是可靠的“计数到二再退出”协议，也不是对任何运行环境的强制保证。

同一进程中其他组件可能也订阅同一信号，因此应由明确的顶层所有者协调。两次快速信号之间也存在调度窗口，不保证第二次一定发生在 stop 之后。若需要准确的升级策略，应单独设计接收和升级逻辑，而不是把一个 Context 当作信号计数器。

SIGKILL 与 SIGSTOP 无法通过 os/signal 捕获；强制终止不能承诺清理完成。Windows 服务控制与 Unix 信号也不是同一个接口，不能把本例直接当成跨平台服务管理方案。

怎样判断退出路径是否完整

读者可以在独立开发环境核对正常退出、端口占用和清理超时三类路径；需要二次信号实验时，应清楚它可能直接终止进程并跳过剩余清理。不要在生产服务上为验证文章示例随意发送信号。

Shutdown 会等 WebSocket 都关闭吗？

不会自动处理被劫持的连接，例如典型 WebSocket 连接。需要应用自己通知并等待这类连接退出，不能把 HTTP Shutdown 成功等同于这些连接都已结束。

stop 是不是让程序立即退出？

不是。它取消返回的 Context 并解除本次信号处理注册。程序何时退出还取决于 main、其他订阅及后续信号；清理完成仍要显式等待。

为什么不能在后台调用 Shutdown 后直接 return？

main 返回就会结束进程。把 Shutdown 放在 goroutine 里并不替你建立等待关系；应由主路径等待它的结果或一个明确的完成通道。

接口细节可查 NotifyContext 文档、Server.Shutdown 文档与 os.Exit 文档。退出生命周期真正需要的是通知、预算和完成条件，而不只是一个信号监听器。