HTTP服务器应使用server.Shutdown()配合带超时的context实现优雅关闭：先拒新连接，再等活跃请求完成，超时后强制终止；需确保handler和中间件响应context取消，避免阻塞；自定义路由需正确暴露并调用底层http.Server.Shutdown()。
HTTP服务器启动后如何避免强制中断导致连接丢失
Go 的 http.Server 默认没有内置优雅关闭逻辑，直接调用 os.Exit() 或收到 SIGKILL 会立即终止所有活跃连接，造成客户端请求被丢弃或响应不完整。真正需要的是：等待正在处理的请求完成、拒绝新请求、超时后强制终止。
核心做法是用 server.Shutdown() 替代 server.Close()，并配合 context.WithTimeout() 控制等待上限：
// 启动服务器
server := &http.Server{Addr: ":8080", Handler: mux}
go func() {
if err := server.ListenAndServe(); err != nil && err != http.ErrServerClosed {
log.Fatal(err)
}
}()
<p>// 收到信号后触发优雅关闭
sig := make(chan os.Signal, 1)
signal.Notify(sig, syscall.SIGTERM, syscall.SIGINT)
</p><p>ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
if err := server.Shutdown(ctx); err != nil {
log.Printf("shutdown error: %v", err)
}</p>
-
server.Shutdown()会先关闭监听器（不再接受新连接），再逐个等待已建立连接完成处理 - 必须传入带超时的
context，否则可能无限等待长连接（如流式接口、WebSocket） - 不要在
Shutdown()前调用server.Close()，否则会提前破坏内部状态，导致Shutdown()失效或 panic
如何确保中间件和 handler 不阻塞 Shutdown 流程
很多自定义中间件（比如日志、认证、限流）或业务 handler 里用了无超时的 time.Sleep()、sync.WaitGroup.Wait() 或未受控的 goroutine，会导致 Shutdown() 卡住——因为这些逻辑不属于 HTTP 连接生命周期，Shutdown() 不会主动中断它们。
关键原则：所有阻塞操作必须可被 context.Context 取消，且 handler 必须监听 req.Context().Done()：
func slowHandler(w http.ResponseWriter, r *http.Request) {
select {
case
- 避免在 handler 中使用
time.Sleep()等不可取消的阻塞调用；改用time.AfterFunc()或结合select+ctx.Done() - 中间件若启动后台 goroutine（如异步审计日志），需在
Shutdown()前显式通知其停止，并用sync.WaitGroup等待结束 - 数据库查询、RPC 调用等必须传入
r.Context()，确保底层驱动能响应 cancel
为什么 net/http.ServeMux 不支持优雅关闭，而自定义 ServeMux 需要额外处理
http.ServeMux 本身只是路由分发器，不持有连接或生命周期控制权，所以它不需要“关闭”。但如果你替换成自定义多路复用器（比如基于 httprouter 或 gin），问题就出在：它们内部可能缓存了未 flush 的响应体、维护了长连接池、或注册了未清理的 signal handler。
实际影响集中在两点：
- 第三方 router（如
gin.Engine）通常封装了http.Server，但默认不暴露Shutdown()接口，需手动获取底层*http.Server实例 - 某些 router 在
Shutdown()后仍尝试写入已关闭的 response writer，引发write tcp ...: use of closed network connection错误 - 如果用了
http2.ConfigureServer()，必须确保Shutdown()前已完成 HTTP/2 连接清理，否则可能 hang 住
建议始终通过 http.Server 原生接口管理生命周期，而非依赖框架封装的 Run() 或 Start() 方法。
测试优雅关闭是否真正生效的三个检查点
本地验证不能只看进程退出，得确认连接行为符合预期。最容易忽略的是：你看到的日志“server shutdown”不代表所有请求都完成了。
- 用
curl -N http://localhost:8080/slow（-N禁用 buffering）发起一个故意延迟的请求，在它返回前发SIGTERM，观察是否返回成功而非 connection reset - 抓包看 TCP 层：正常流程应是服务端先发 FIN（关闭监听），再等 client FIN 后才发第二个 FIN；若直接 RST，则说明没走
Shutdown() - 监控
http.Server.ConnState回调，打印http.StateClosed和http.StateHijacked数量，确认所有连接最终进入 Closed 状态
最常漏掉的是对长连接（如 SSE、gRPC-Web）的测试——它们可能维持几十秒，超时设置必须覆盖这类场景，且 handler 内部必须响应 context cancel。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
