Go热重启需父子进程协作：老进程等待请求结束并传递listener fd给新进程，新进程用net.FileListener复用fd监听，仅http.Server.Shutdown()无法启动新进程或传递fd。
Go 语言热重启不是靠“不退出”，而是靠父子进程协作：老进程等完请求再退，新进程复用老 listener 的文件描述符（fd）来接新连接。直接 os.Exit(0) 或杀进程必然触发 TCP RST，客户端立刻断连；只调 http.Server.Shutdown() 也不够——它只关旧服务，不拉新进程。
为什么 http.Server.Shutdown() 单独用不行
Shutdown() 是优雅关闭的必要条件，但不是热重启的充分条件。它只做一件事：等待活跃 HTTP 请求自然结束或超时，然后关闭 listener。它不启动新进程，也不传递 socket。
- 常见错误：收到
SIGUSR2后只调srv.Shutdown(ctx)就os.Exit(0)—— 这等于优雅关机，不是重启 - 新进程若没拿到 fd，
net.Listen("tcp", ":8080")必报bind: address already in use -
Shutdown()的ctx必须干净：不能是context.WithCancel(parentCtx)，否则父 ctx 一 cancel，shutdown 就提前终止 - 超时建议设
30–60 * time.Second；太短会强杀大文件上传，太长拖慢发布节奏
如何安全传递 listener 的文件描述符
关键在 Unix 系统的 fd 继承机制。新进程不能自己 bind，必须从父进程“继承”已打开的监听 socket。
- 父进程调
ln.(*net.TCPListener).File()拿到*os.File，记下其file.Fd()（比如是3） - 启动子进程时，用
os.StartProcess并在sys.ProcAttr.Files中显式传入[]uintptr{... , 3}—— 缺这个，子进程根本看不到该 fd - 子进程启动后第一件事：读环境变量（如
os.Getenv("LISTEN_FD")），调os.NewFile(3, "")恢复*os.File，再用net.FileListener(file)转成可监听的net.Listener - 务必验证：用
lsof -i :8080查看，重启过程中应同时看到两个 PID 在监听同一端口
信号处理与父子进程协同时机
最容易出问题的是“谁先放手、谁先接手”的竞态。新进程不能一启动就 Accept()，老进程也不能一发信号就立刻 Shutdown()。
- 推荐用
SIGUSR2（而非SIGHUP）：Kubernetes 和 systemd 默认发SIGTERM，SIGHUP容易被忽略或误配 - 父进程收到信号后，先调
ln.(*net.TCPListener).File()，再 fork 子进程并传 fd；之后才调srv.Shutdown() - 子进程拿到 fd、构造好
net.Listener、启动http.Server.Serve()后，必须显式通知父进程“我已就绪”——例如通过 Unix socket 或临时文件，否则父进程可能过早退出 - Windows 不支持 fd 继承，此方案仅限 Linux/macOS/BSD
别碰已停更的第三方库
endless、graceful、facebookgo/grace 这些库大多停止维护，且存在硬伤：
-
endless最后更新是 2021 年，不兼容 Go 1.21+ 的syscall变更；内部隐式依赖SIGHUP，和现代编排系统冲突 - 它们用过时的
syscall.ForkExec，在 macOS 和新版 glibc 上易出错 - 封装过深，出问题难调试；比如新旧进程 accept 争抢、listener 未正确关闭、信号未注册等，日志里往往只显示 “connection reset”
- 真正可控的做法：手写
signal.Notify+os.StartProcess+net.FileListener，逻辑透明，适配你自己的超时策略和就绪判断
最常被忽略的一点：新进程启动后，父进程必须等它真正开始 Accept()，才能调 Shutdown()。否则会出现短暂的“无进程监听”，新连接直接失败。这个“就绪”不能靠 sleep 猜，得靠进程间通信确认。
