Go 的 http.Server.Shutdown() 是唯一推荐的优雅关闭方式，因它能拒绝新连接、通知活跃连接终止、等待 handler 主动退出；而 Close() 会丢弃 Accept 中连接且不等待已建立连接，导致请求中断和 goroutine 泄漏。
Go 的 http.Server.Shutdown() 是唯一推荐的优雅关闭方式，直接调用 Close() 或 os.Exit() 会导致请求中断、连接重置、数据丢失。
为什么必须用 Shutdown() 而不是 Close()
Close() 立即关闭 listener，所有正在 Accept 的连接会被丢弃，新请求立刻失败（返回 ErrServerClosed），但已建立的连接仍可能在处理中——这些连接不会被通知终止，也不会被等待，服务端可能 panic 或 goroutine 泄漏。Shutdown() 则会：
• 立即拒绝新连接（Accept() 返回错误）
• 向所有活跃连接发送 FIN，触发 conn.CloseRead() 和超时机制
• 等待每个连接的 Handler 主动退出（前提是 handler 自身支持 context 取消）
• 所有连接完成或超时后才真正返回
标准流程：信号监听 + 带超时的 Shutdown()
关键三步缺一不可：启动服务不阻塞主 goroutine、监听 SIGINT/SIGTERM、用带 deadline 的 context 控制关闭时限。
package main
<p>import (
"context"
"log"
"net/http"
"os"
"os/signal"
"syscall"
"time"
)</p><p>func main() {
http.HandleFunc("/", func(w http.ResponseWriter, r <em>http.Request) {
// 注意：真实 handler 应检查 r.Context().Done()
log.Println("handling request...")
time.Sleep(3 </em> time.Second)
w.Write([]byte("ok"))
})</p><pre class='brush:php;toolbar:false;'>srv := &http.Server{Addr: ":8080"}
// 1. 非阻塞启动
go func() {
log.Println("server starting on :8080")
if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
log.Fatal(err)
}
}()
// 2. 监听退出信号
quit := make(chan os.Signal, 1)
signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)
// 3. 收到信号后执行 Shutdown，带 10 秒兜底超时
<-quit
log.Println("shutting down gracefully...")
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
if err := srv.Shutdown(ctx); err != nil {
log.Printf("shutdown error: %v", err) // 可能是 context.DeadlineExceeded
}
log.Println("server exited")}
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
常见踩坑点：handler 不响应 context、没设超时、goroutine 泄漏
• handler 忽略 r.Context()：比如用 time.Sleep(10 * time.Second) 硬等，Shutdown() 无法中断它，最终超时强制退出，请求失败。
• 没设 context.WithTimeout：若 handler 卡死（如死循环、未响应的 DB 查询），Shutdown() 永远不返回，进程 hang 住，只能 kill -9。
• 后台 goroutine 未清理：比如你在 handler 里启了子 goroutine 但没传 r.Context() 或没监听 done channel，它们会在 server 关闭后继续运行，造成资源泄漏。
• 重复调用 Shutdown()：第二次调用会立即返回 ErrServerClosed，但不影响正确性；不过逻辑上应确保只调一次。
进阶注意：HTTP/2、长连接、自定义 Listener 的影响
• HTTP/2 连接复用下，单个连接承载多个请求，Shutdown() 会等该连接上所有流（stream）自然结束，不能强制中断单个 stream。
• 若用了自定义 net.Listener（如 TLS、SO_REUSEPORT），需确保其 Close() 方法能快速返回，否则 Shutdown() 会卡在 closeListenersLocked()。
• 对 WebSocket 或 SSE 等长连接，务必在 handler 中监听 r.Context().Done() 并主动关闭底层 conn，否则连接会一直挂着直到超时或客户端断开。
真正决定“是否优雅”的从来不是 shutdown 调用本身，而是 handler 是否尊重 context、后台任务是否可取消、超时是否合理——这些地方写错一行，整个优雅关闭就失效了。
