go http server 应使用 http.server.shutdown() 实现优雅关闭：先停监听、再等活跃连接完成，需配合 context 超时、设置读写超时、确保 handler 响应上下文取消，且注意 k8s 和反向代理配置。
Go HTTP Server 关闭时为什么会出现连接中断？
直接调用 server.Close() 会立即拒绝新连接，并关闭所有活跃连接，导致正在处理的请求被强制终止（如大文件上传、长轮询、流式响应）。这不是“优雅”，而是“粗暴”。真正需要的是：允许已接受的连接完成处理，同时拒绝新连接。
使用 http.Server.Shutdown() 是唯一推荐方式
Shutdown() 会先关闭监听器（不再接受新连接），再等待所有现存连接完成处理（或超时）。它依赖 context.Context 控制等待时限，必须配合信号监听使用。
关键点：
-
Shutdown()不是阻塞调用，需主动Wait或用context.WithTimeout管理超时 - 必须提前设置
server.ReadTimeout和server.WriteTimeout，否则某些挂起连接可能永远不结束 - 若 handler 中有未受控的 goroutine（如启用了
time.AfterFunc但没传 cancel），它们不会被Shutdown()自动清理
最小可行示例：
立即学习“go语言免费学习笔记（深入）”；
srv := &http.Server{Addr: ":8080", Handler: myHandler}
go func() {
if err := srv.ListenAndServe(); err != http.ErrServerClosed {
log.Fatal(err)
}
}()
<p>// 收到 SIGINT/SIGTERM 后触发
sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)
<-sigChan</p><p>ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
if err := srv.Shutdown(ctx); err != nil {
log.Fatal("server shutdown error:", err)
}
如何确保中间件和 handler 配合优雅退出？
很多中间件（如日志、JWT 验证）本身不阻塞，但自定义 handler 若含长耗时逻辑（如数据库事务、外部 HTTP 调用），需主动支持上下文取消。
常见错误写法：time.Sleep(5 * time.Second) —— 它不响应 ctx.Done()；应改用 time.Sleep 前加 select 判断，或用 time.AfterFunc + ctx 控制。
正确姿势：
- 所有阻塞 I/O 操作（
http.Client.Do、database/sql.QueryRowContext、redis.Conn.Do）必须传入req.Context() - 自定义 goroutine 必须监听
ctx.Done()并做清理（如关闭 channel、释放锁） - 避免在 handler 中启动无取消机制的后台 goroutine（如
go sendToKafka(...)）
生产环境还需注意哪些细节？
真实部署中，优雅退出常被忽略的环节比代码本身更关键：
- Kubernetes 中，需配置
terminationGracePeriodSeconds（默认 30s），它必须 ≥Shutdown()的 timeout，否则 pod 会被强制 kill - 反向代理（如 Nginx、Traefik）可能缓存连接或重试失败请求，建议在
Shutdown()前先下线服务注册（如 Consul、etcd） - 若用
net/http.Serve手动接管 listener（例如 TLS reload 场景），要自己管理 listener.Close() 和 active conn tracking，此时Shutdown()不适用，得手动实现类似逻辑
最易被跳过的点：没有给 Shutdown() 设超时，或设得太短（如 1s），导致大量请求被丢弃；也没有验证 handler 是否真响应了 ctx.Done() —— 这会让整个“优雅”变成幻觉。
