Go 收到 SIGTERM 后怎样给 HTTP 请求留下清理时间

Go 服务收到 SIGTERM 后，不能只在信号通道里打印一行日志再直接退出。比较稳妥的做法是：用 signal.NotifyContext 把信号转换成取消事件，停止接收新连接，再给 http.Server.Shutdown 一个明确的截止时间。这样正在处理的 HTTP 请求可以完成必要的收尾，超时请求也不会把进程拖成无限等待。

先把 SIGTERM 变成可传播的取消信号

Go 对 SIGTERM 的默认行为是退出进程。接入 signal.NotifyContext 后，程序可以先得到一个派生 context，再决定怎样关闭 HTTP 服务。这个函数从 Go 1.16 起提供；它会在指定信号到达、父 context 取消或主动调用 stop 时关闭返回 context 的 Done 通道。

这里的 stop 不是可有可无的语法。它会撤销信号行为并释放相关资源，适合在主清理流程结束后调用。若只写成“收到信号就 cancel”，却不安排 stop，长期运行的测试进程或重复创建服务的代码更容易留下信号接管状态。

让 HTTP 服务拥有清晰的关闭边界

小项目可以用一个 http.Server 串起启动、等待和关闭三个阶段。下面的代码没有把 ListenAndServe 放进不可控的阻塞逻辑里，而是单独处理它的返回值：

package main

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

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/slow", slowHandler)
    srv := &http.Server{Addr: ":8080", Handler: mux}

    // 把 SIGTERM 转为根取消信号，后续清理统一从 ctx.Done() 触发。
    ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGTERM, os.Interrupt)
    defer stop()

    serveErr := make(chan error, 1)
    go func() {
        // ListenAndServe 在正常 Shutdown 后会返回 ErrServerClosed。
        serveErr 

这里使用带缓冲的错误通道，避免服务 goroutine 在主流程暂时还没接收时卡住。收到 SIGTERM 后，Shutdown 会先关闭监听器和空闲连接，再等待活动连接回到空闲状态；所以 ListenAndServe 返回 http.ErrServerClosed 是正常收尾信号，不应按启动故障记录。

清理窗口应该怎样传给下游请求

优雅退出只解决 HTTP 服务的入口，不能自动中断所有数据库查询、RPC 调用或自建 goroutine。处理函数应沿着调用链传递 r.Context()，并在派生超时 context 后调用对应的取消函数。例如数据库查询应使用 QueryContext 一类接受 context 的 API；客户端断开连接时，请求 context 也会被取消。

需要注意两种时间不要混在一起：请求自己的业务超时，和进程退出时给全局清理留下的时间。前者通常从 r.Context() 派生，后者由 Shutdown 接收一个独立的关闭 context。把已经取消的请求 context 直接拿来控制全局 Shutdown，可能导致服务刚收到信号就没有清理窗口。

几个容易误判的退出场景

如果服务运行在容器或编排平台中，8 秒只是示例，不是通用答案。它至少要覆盖正常请求的收尾时间，并短于平台真正的强制终止窗口。生产环境还应确认健康检查会在停止监听后摘除实例，避免新流量继续进入正在退出的副本。

常见问题

为什么不直接调用 srv.Close？

Close 会立即关闭活动连接；需要给正在处理的请求机会时，应优先使用 Shutdown，再用截止时间约束最长等待。

为什么调用 stop 后还要等待 serveErr？

stop 只负责恢复信号处理和释放信号资源，不等于 HTTP 监听 goroutine 已经结束。等待 serveErr 可以避免主函数提前退出。

这套结构的核心不是“收到 SIGTERM 后多睡几秒”，而是把信号、HTTP 监听、请求取消和资源清理放进同一条可观察的取消链，并为链条末端设定硬截止时间。