http.server.shutdown 不能替代信号处理，因为shutdown本身需由信号触发；它先关闭监听器、再等待活跃请求完成（支持超时），而server.close()会立即中断所有请求，导致502/503或数据截断。
为什么 http.Server.Shutdown 不能直接用信号处理替代
很多人以为监听 SIGTERM 后调用 server.Close() 就算平滑关闭，但这是错的：server.Close() 会立刻拒绝新连接、并中断所有正在处理的请求（包括长轮询、流式响应、上传中请求），导致 502/503 或数据截断。http.Server.Shutdown 才是标准解法——它先关闭监听器，再等待活跃连接自然结束（可设超时），期间仍能完成已接受的请求。
实操建议：
- 必须在调用
Shutdown前启动一个独立 goroutine，否则会阻塞主流程； - 超时时间要大于业务最长请求耗时（比如上传大文件需设 30s+），但别过长（否则进程僵死）；
- 务必捕获
context.DeadlineExceeded错误，它表示有请求未及时退出，此时应记录日志而非 panic； - 若服务含 gRPC、WebSocket 或自定义 TCP 连接，需单独管理它们的生命周期，
http.Server.Shutdown不覆盖这些。
如何让热重启不丢连接：用 net.File 复用监听 socket
热重启本质是父进程把监听 socket 通过 os.File 传给子进程，子进程用它启动新服务，父进程等旧连接结束后再退出。Go 标准库不直接支持，得靠 syscall.UnixRights 和 os.NewFile 配合 exec.Cmd.ExtraFiles 实现。
常见错误现象：子进程报 bind: address already in use，或父进程退出后新连接被拒绝——说明 socket 没正确传递或没设置 SO_REUSEPORT。
实操建议：
- 父进程创建 listener 后，用
l.(*net.TCPListener).File()获取*os.File，传给子进程作为第 3 个 fd（前两个是 stdin/stdout）； - 子进程中用
os.NewFile(3, "")恢复 listener，再调用http.Serve(l, mux)； - 必须在 listener 创建时启用
SO_REUSEPORT（Go 1.11+ 可用&net.ListenConfig{Control: controlFunc}设置）； - 不要用
os.StartProcess，改用exec.Command并显式设置Cmd.ExtraFiles = []*os.File{nil, nil, file}； - 父进程收到
SIGHUP后，先 fork 子进程，再等子进程就绪（比如通过临时文件或 HTTP 健康检查确认），最后才开始Shutdown。
gracehttp 和 fvbock/grace 这类库到底该不该用
它们封装了 socket 传递和信号处理，但隐藏了关键细节：比如默认超时硬编码为 30s、不暴露底层 listener 控制权、对非 HTTP 服务（如 Prometheus metrics 端点单独监听）支持弱。线上出问题时，你很难快速判断是库逻辑缺陷还是自己配置错。
使用场景建议：
- 内部工具、CI 服务、低流量后台任务——用
gracehttp能省 20 行代码，风险可控； - 网关、支付回调、实时消息推送等核心链路——建议手写，重点控制三处：
Shutdown超时、socket 传递失败降级逻辑（比如 fallback 到冷重启）、子进程启动失败时的回滚机制； - 若选库，必须重写其信号注册逻辑（比如屏蔽
SIGUSR2防止冲突），并 patch 其 health check 路径，避免和业务路由重复； - 所有库都依赖
os.Getpid()和os.Getppid()判断父子关系，容器环境下（如 Kubernetes）可能不准，需额外验证/proc/$PID/status中的PPid。
真实部署时最常被忽略的三个点
热重启不是写完代码就完事。Kubernetes 的 preStop hook、systemd 的 KillMode、Nginx upstream 的 max_fails 都会影响最终效果。
实操要点：
- K8s 中
preStop必须设为sleep 30 && kill -TERM $PID，且terminationGracePeriodSeconds要 ≥ Shutdown 超时 + 子进程启动耗时； - systemd 服务需设
KillMode=mixed（否则主进程一杀，子进程全被连带 kill）； - 反向代理（如 Nginx）要把上游健康检查路径指向一个轻量 endpoint（比如
/healthz），且配置fail_timeout=5s max_fails=1，避免因单次热重启抖动触发误摘流； - 日志里必须打上
pid和ppid，否则分不清是哪个进程处理的请求，排查超时问题时会卡死。
