go中http.server不能直接调用close()，因其会立即终止监听并强制中断正在处理的请求；优雅关闭需先停收新连接、再等待已有请求完成，标准做法是用带超时的context调用shutdown()并配合sync.once防重复。
Go 中 http.Server 为什么不能直接调用 Close() 就完事？
直接调用 srv.Close() 会立即终止监听，正在处理的请求（尤其是长连接、流式响应、未写完的 body）会被强制中断，客户端收到 connection reset 或不完整响应。这不是“优雅”，是“粗暴关机”。真正优雅关闭的核心是：先停止接受新连接，再等待已有请求自然完成，超时后强制终止。
标准写法：用 Shutdown() 配合 context.WithTimeout()
Shutdown() 是 Go 1.8+ 提供的官方优雅关闭入口，它会做三件事：关闭 listener、等待活跃连接关闭、拒绝新连接。但它本身不带超时——必须你自己传入带超时的 context.Context，否则可能永远等下去。
常见错误是传 context.Background() 或忽略返回错误：
err := srv.Shutdown(context.Background()) // 错！没超时，卡死风险
if err != nil {
log.Fatal(err) // 错！Shutdown 超时返回 context.DeadlineExceeded，不该 fatal
}
正确做法：
- 用
context.WithTimeout(ctx, 10*time.Second)控制最大等待时间 - 调用
srv.Shutdown()后，检查错误是否为context.DeadlineExceeded，仅记录 warn，不 panic - 确保
http.Server的ReadTimeout/WriteTimeout已合理设置，避免个别慢请求拖垮整个 shutdown 流程
信号捕获与并发安全：os.Signal 和 sync.Once 的配合
优雅关闭通常由系统信号（如 SIGINT、SIGTERM）触发，但信号可能多次到达，而 Shutdown() 只能调用一次。重复调用会 panic：http: Server closed。
必须用 sync.Once 包一层，保证 shutdown 逻辑只执行一次：
var shutdownOnce sync.Once
sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)
go func() {
<-sigChan
shutdownOnce.Do(func() {
log.Println("shutting down server...")
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
if err := srv.Shutdown(ctx); err != nil {
log.Printf("server shutdown error: %v", err) // 不 panic
}
})
}()
注意：srv.ListenAndServe() 应该在 main goroutine 中阻塞运行，不要用 go srv.ListenAndServe() 后立刻往下走——否则 main 退出进程就结束了，shutdown 还没来得及执行。
测试 shutdown 是否真生效：别只看日志
容易被忽略的是：即使 shutdown 逻辑写了，也可能因 handler 里用了无限制的 time.Sleep、死循环、或未响应 ctx.Done() 而卡住。真实验证方式：
- 启动服务后，用
curl -N http://localhost:8080/slow模拟一个 15 秒响应的 endpoint - 发
SIGTERM，观察是否在 10 秒后强制结束（而非等满 15 秒） - 检查连接数变化：
lsof -i :8080 | wc -l，shutdown 前后应明显下降 - 关键点：handler 必须主动检查
http.Request.Context().Done()并提前退出，否则Shutdown()等不到它
超时控制不是加个 WithTimeout 就万事大吉，它只管“等多久”，不管“里面干了什么”。真正的优雅，藏在每个 handler 对 context 的尊重里。
