零停机平滑重启需手动接管http.Server生命周期并用SIGUSR2触发子进程继承监听套接字，router.Run()因封装Server不暴露实例而无法支持；Shutdown()仅实现优雅关闭，非零停机；真正零停机依赖套接字继承+SIGUSR2协同；endless库虽封装流程但受限于静态编译、无cgo等条件。
零停机平滑重启在 Gin 中不是“开个开关就自动生效”，而是必须手动接管 http.Server 生命周期，并用 SIGUSR2 触发子进程接管监听套接字 —— 否则所有热重启方案都只是优雅关闭，不是真正零停机。
为什么 router.Run() 无法支持零停机重启
直接调用 router.Run(":8080") 会内部调用 http.ListenAndServe()，该函数封装了 http.Server 实例但不暴露出来，导致你无法调用 Shutdown()，更无法传递监听文件描述符给子进程。
- 它把
net.Listener创建、Server.Serve()启动、错误阻塞逻辑全打包隐藏了 - 没有监听器引用，就无法在收到
SIGUSR2时把它传给新进程 - 即使你用
os/exec启动新进程，旧进程也没法把 socket 文件描述符（如fd=3）安全移交
http.Server.Shutdown() 只解决优雅关闭，不解决零停机
Shutdown() 是优雅关闭的基石，但它本身不创建新进程、不继承监听套接字 —— 它只让当前进程“等完手头活再关门”。零停机需要的是“老门卫交班，新门卫立刻上岗”，而 Shutdown() 只负责让老门卫退场。
- 调用
Shutdown()后，Listener.Accept()立即返回ErrServerClosed，新连接被拒绝 - 已建立的连接继续处理，但没人接替监听 —— 中间存在毫秒级空白期（尤其在高并发下可被负载均衡器探测到）
- 若配合
fork/exec，必须在父进程调用Shutdown()前，把Listener的文件描述符通过ExtraFiles传给子进程
真正零停机必须靠套接字继承 + SIGUSR2 协同
Linux 内核允许父子进程共享打开的文件描述符。零停机重启的本质，是让子进程用父进程已绑定的 socket 继续 accept 连接，同时父进程不再 accept 新连接但完成已有请求。
- 父进程监听时，拿到的
net.Listener对应一个内核 socket（比如 fd=3） - 收到
SIGUSR2后，父进程用os/exec.Cmd.ExtraFiles把 fd=3 传给子进程，并设置环境变量如LISTENER_FD=3 - 子进程启动后，调用
os.NewFile(3, "listener")→net.FileListener(file)恢复监听器，立即开始 accept - 父进程随后调用
Shutdown()，等待活跃请求结束，再退出
这一步漏掉任意一环 —— 比如没传 fd、子进程没正确重建 listener、父进程没等完请求就 exit —— 都会导致连接丢失或端口占用冲突。
endless 库做了什么，以及它容易被忽略的限制
fvbock/endless 封装了上述流程，但它的行为高度依赖运行时环境：它假设你的二进制是静态编译的、没有 cgo、且未使用某些 net 包的非标准初始化方式。
- 它会拦截
SIGUSR2，自动 fork 自身，传递LISTENER_FD和GRACEFUL_RESTART=true - 子进程里调用
net.FileListener()恢复监听，父进程调用Shutdown() - 但它不兼容
CGO_ENABLED=1且使用 sqlite、openssl 等 cgo 依赖的场景 —— 此时 fork 后子进程可能 panic - 它也不处理多 listener 场景（比如同时监听 :80 和 :443），需手动扩展
真正上线前，必须用 strace -e trace=bind,listen,accept,close 验证父子进程是否真的复用了同一个 socket fd，而不是各自 bind 成功却实际断连。
