Go Server Shutdown 等待过久的连接收敛

http.Server.Shutdown 等待过久，通常要先查尚未完成的请求，而不是反复关闭监听器。它会停止监听、关闭空闲连接，并等待活跃连接空闲；传入没有期限的context时，这段等待可能持续很久。应当给优雅退出独立的时间预算，再明确超时后是否调用Close中断普通HTTP连接。

官方地址：https://pkg.go.dev/net/http#Server.Shutdown

把问题放进一次服务退出场景：监听已经返回ErrServerClosed，进程却还没结束。此时最有价值的基线是停机调用耗时、尚未返回的处理器数量和长连接类别。本文给出采集与判断方法，不编造线上耗时、压测数据或优化比例。

监听退出和请求处理结束是两件事

Shutdown被调用后，ListenAndServe会很快返回 http.ErrServerClosed。这个错误说明监听服务进入关闭状态，不说明所有请求已经完成。主函数如果此时直接return，进程会退出，优雅等待也就没有机会完成。

另一方面，主函数如果确实在等待Shutdown，而处理器仍在写流式响应、等待外部接口或持有长事务，等待就是符合该接口语义的行为。先区分主函数过早退出和活跃请求迟迟不结束，修复方向完全不同。

从在途请求指标找到等待对象

建议在处理器入口增加在途计数，返回时减少，并按路由模板记录耗时与取消原因。计数对象是请求，不是TCP连接；HTTP/2连接可以承载多个请求，不能把ConnState的活跃连接数直接当成请求数。

若停机时在途数量始终不下降，应进一步查看请求是否缺少业务期限、数据库查询是否传递请求context、外部请求是否有超时，以及处理器是否等待永远不会关闭的channel。只缩短Shutdown期限，会更快返回错误，却不会修复这些等待来源。

Shutdown的context约束的是停机等待，不会因为开始优雅关闭就自动取消所有处理器的请求context。需要主动通知流式处理器结束时，应设计单独的服务排空信号，并让处理器在安全位置响应它。若把所有请求直接绑定到信号context，收到信号立即取消也会改变“允许在途请求完成”的策略。

为停机创建独立期限，并保留主函数等待

以下示例选择8秒优雅等待预算，超时或其他Shutdown错误后关闭普通HTTP连接。这是示例策略，不是通用推荐值。代码只演示HTTP服务器生命周期，不包含WebSocket注册表或业务后台任务，且未在本文环境运行。

package main

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

func main() {
    stop, releaseSignal := signal.NotifyContext(context.Background(),
        os.Interrupt, syscall.SIGTERM)
    defer releaseSignal()

    mux := http.NewServeMux()
    mux.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
        w.WriteHeader(http.StatusNoContent)
    })
    srv := &http.Server{
        Addr: "127.0.0.1:8080",
        Handler: mux,
        ReadHeaderTimeout: 5 * time.Second,
    }
    serveErr := make(chan error, 1) // 监听退出不会因主协程尚未接收而阻塞。
    go func() {
        serveErr 

这里用 context.Background() 创建停机context，是因为信号context已经取消；如果从它派生，Shutdown可能立即得到取消错误，根本没有预期的8秒等待窗口。ReadHeaderTimeout只约束读取请求头，不能替代停机期限，也不能为整个处理器设置业务超时。

Server.Close 会直接关闭普通活跃连接，可能让调用方收到中断。它不是“更快且同样无损的Shutdown”，也不保证任意阻塞业务协程都已经结束。若处理器忽略取消或后台任务脱离请求生命周期，仍需自己的完成通知和有界等待。

WebSocket和后台任务需要自己的关闭约定

官方文档明确指出，Shutdown既不会关闭也不会等待已劫持连接，例如WebSocket。Close同样不知道这些连接。它们通常不会直接成为Shutdown内置等待的对象，但应用自己等待长连接管理器时，整个进程仍可能卡住。

应用应登记升级连接，发出协议允许的关闭通知，并在独立截止时间内等待退出。RegisterOnShutdown 可以启动协议相关的关闭动作，但回调不应阻塞等待协议结束；完整的等待屏障应由应用另行持有。不能把“回调已触发”写成“所有长连接已关闭”。

通过HTTP流式响应保持的SSE处理器则仍属于普通活跃请求，应当响应排空信号或自身期限，完成必要输出后返回。它与已劫持WebSocket的管理方式不能混在同一个假设里。

用同一组请求检查退出语义

这是一组回归设计，不是已运行的测试结果。比较改动前后时，应固定请求类型、请求持续时间和并发条件，同时观察完整响应率、强制关闭数与停机耗时。仅让进程更早退出却增加大量中断，不足以说明问题已解决。

部署的总退出预算还要覆盖流量摘除、HTTP排空、长连接通知和其他资源清理。应用8秒不是平台总预算；外层管理器若更早终止进程，代码中的等待无法兑现。各阶段可以共享一个总体期限，避免每个步骤各自再等完整预算。

相关问题

把Background传给Shutdown有错吗？

接口允许，但它没有截止时间。对有明确退出期限的服务，应使用带超时或截止时间的context；无限等待必须是有意选择。

调用Close后还能保证请求成功吗？

不能。活跃连接可能被中断，业务写入和客户端接收也不等价。需要幂等与事务设计的接口应单独处理重试和提交语义。

Shutdown后还能重新ListenAndServe吗？

同一个Server不能复用。需要再次启动服务时，应创建新的Server并重新安排其资源生命周期。

排查时先确认等待的是普通请求、应用长连接还是后台任务，再为每一种资源安排通知、期限和完成条件。这样记录下来的停机耗时才有可解释的含义。

参考：Shutdown语义；Close管理范围；停机通知回调。