http.Server 的优雅关闭与超时控制写法

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 的尊重里。