Go语言平滑重启不是热更新，而是新旧进程交接监听socket：Shutdown()仅优雅关闭旧进程，不启动新进程、不传递fd；必须手动用SIGUSR2触发，通过ExtraFiles传递fd，子进程用os.NewFile(3,"")和net.FileListener复用端口，且Addr需为空字符串""。
Go 语言在微服务中实现平滑重启，不是靠“热更新代码”，而是靠进程间交接监听 socket —— 新二进制启动、复用旧进程的端口 fd，旧进程等请求自然结束。真正在生产环境能落地的，只有这一种方式。
为什么直接调 http.Server.Shutdown() 不等于平滑重启
http.Server.Shutdown() 只控制旧进程退出时机，它不拉起新进程，也不传递监听 socket。只写这一句就上线，结果是服务中断、curl: (7) Failed to connect、监控里 5xx 突增。
- 现象：lsof -i :8080 只显示一个 PID；重启后端口短暂不可用；客户端偶发
connection reset by peer - 本质原因：旧进程关了 listener，新进程还没起来，或根本没尝试复用 fd
- 关键区别：
Shutdown()是“优雅关闭”，不是“热重启”——后者必须包含子进程启动 + fd 传递 + 复用监听
如何用标准库手写 SIGUSR2 触发的平滑重启逻辑
别依赖已归档的 endless 或 graceful：前者不兼容 Go 1.22+ 的 syscall 变更，后者默认监听 SIGHUP，而 Kubernetes 和 systemd 发的是 SIGTERM，信号收不到就卡死。
- 主进程监听
syscall.SIGUSR2（Linux/macOS 通用），SIGTERM留给正常关闭用 - 收到
SIGUSR2后，立刻执行ln.(*net.TCPListener).File()获取*os.File，记下其Fd()（通常是 3） - 用
exec.Command(os.Args[0], os.Args[1:])启动子进程，并把 fd 加入cmd.ExtraFiles：例如[]*os.File{file} - 父进程紧接着调
server.Shutdown(ctx)，ctx 来自context.WithTimeout(context.Background(), 45*time.Second)；切勿写defer cancel()，否则 ctx 提前失效
子进程如何正确复用父进程的 net.Listener
子进程不能调 net.Listen()，否则必然报 address already in use。它必须从 ExtraFiles 恢复 fd，并绕过地址绑定检查。
立即学习“go语言免费学习笔记（深入）”；
- 子进程启动后第一件事：取第 0 个 extra file（对应 fd=3），调
os.NewFile(3, "")→net.FileListener(file) -
http.Server.Addr必须设为空字符串""，否则server.Serve(ln)会尝试重新 bind，触发冲突 - 监听 socket 必须启用
SO_REUSEPORT（Linux）或SO_REUSEADDR（macOS/BSD）：创建 listener 后加一句ln.(*net.TCPListener).SetReusePort(true) - 若用 fasthttp，必须调
server.Serve(listener)，不能用ListenAndServe()；gin/echo 需确认是否暴露StartListener()，否则得自己封装net.Listen
最容易被忽略的初始化细节
新进程不是旧进程的内存镜像，所有运行时依赖都得重来——哪怕只差一行初始化，都会导致 panic 或静默失败。
- HTTP handler 里读取的配置、数据库连接池、日志实例，必须在新进程中重新初始化；旧进程的
fd、mutex、channel在新进程里完全无效 - gRPC server、WebSocket 连接、自定义 TCP 服务不被
http.Server.Shutdown()覆盖，需单独管理生命周期 - 健康检查端点（如
/health）若单独监听，也要走同样 fd 传递流程，否则子进程无法响应探针
