go服务平滑重启和优雅关闭的核心是http.server.shutdown()配合信号监听与带超时context，且必须通过fd复用socket；缺一不可，否则丢请求、断连接、泄漏goroutine。
go服务平滑重启和优雅关闭网络连接，核心就一条：必须用 http.server.shutdown() 配合信号监听与带超时的 context.context，同时确保新旧进程通过文件描述符（fd）复用监听 socket——缺一不可。直接调 os.exit(0)、server.close() 或只写 shutdown() 却不监听信号，都会丢请求、断长连接、泄漏 goroutine。
为什么 http.Server.Shutdown() 必须配信号监听
Shutdown() 本身不触发退出，它只是“开始等待”：停止 accept 新连接，但会一直等已有请求自然结束。若没监听 SIGINT 或 SIGTERM，程序就卡在运行中，Ctrl+C 无响应，容器里会被强制 kill -9。
- 必须用
signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)注册信号通道 - 不能只监听
SIGHUP：systemd 默认发SIGTERM，而SIGHUP常被拦截或用于配置重载 - 收到信号后，立刻启动
Shutdown()，别加任何中间逻辑（比如先 flush 日志再 shutdown）——这会延迟关闭窗口 - 若用
SIGUSR2做热重启，注意它不会被 systemd 默认转发，需显式配置KillSignal=SIGUSR2
如何避免 Shutdown() 卡住不返回
卡住 = 有 handler 还在阻塞，且没响应 ctx.Done()。常见于数据库查询、HTTP 调用、time.Sleep() 等未受控操作。
- 超时 context 必须干净：
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)；不要 defer cancel()，否则Shutdown()没开始就取消了 - 所有阻塞调用必须用带 ctx 的版本：
db.QueryContext(ctx, ...)、http.DefaultClient.Do(req.WithContext(ctx)) -
http.Server.ReadTimeout和WriteTimeout不影响Shutdown()行为，它们只管单次读写，不是整个请求生命周期 - 中间件里启动的 goroutine（如日志异步刷盘）必须监听同一
ctx，否则会拖慢 shutdown
热重启时怎么复用监听 socket 而不报 address already in use
Linux 下不能靠“新进程自己 listen”，必须把老 listener 的 fd 传给新进程。标准库不提供自动支持，得手动做。
- 老进程收到
SIGUSR2后，调ln.(*net.TCPListener).File()获取*os.File，记下file.Fd()（如 3） - 启动子进程时，把 fd 编号写进环境变量（如
LISTEN_FD=3），并确保Files字段包含该 fd - 新进程启动后第一件事：读
os.Getenv("LISTEN_FD")，用os.NewFile(3, "")恢复*os.File，再用net.FileListener(file)转成net.Listener - 验证是否成功：
lsof -i :8080应同时看到两个 PID；若只看到一个，说明 fd 传递失败或新进程没调net.FileListener
长连接中断的根本原因和修复点
客户端收到 connection reset by peer 或大量 CLOSE_WAIT，通常不是网络问题，而是服务端生命周期管理错位。
- 别在 handler 里用
conn.SetReadDeadline()后忽略io.EOF：当Read()返回n == 0 && err == io.EOF，必须立刻conn.Close()，否则空转 CPU - 新进程接管 listener 后，旧进程不能立刻
Shutdown()——要等新进程成功Accept()到第一个连接，再发信号，否则存在竞态窗口 - 若用了反向代理（如 Nginx），它的 idle timeout（常为 60s）必须大于服务端
Shutdown()超时，否则连接在服务端还没关完就被代理断开 - goroutine 泄漏最常发生在：handler 启动了后台 goroutine 却没传入
ctx，也没监听ctx.Done()
真正难的不是写几行 Shutdown()，而是让每个 handler、每层中间件、每个依赖客户端都对同一个 ctx 敏感；更麻烦的是 fd 传递的时序控制——父进程何时 fork、子进程何时 ready、旧连接何时真正 drain 完，这些边界稍有偏差，就会在高并发下暴露问题。
