Go服务热升级本质是双进程切换：旧进程用http.Server.Shutdown()等待请求结束，新进程通过exec.Command传递listener文件描述符复用端口，配合SIGUSR2信号触发，实现零中断切换。
如何用 exec.Command 启动新进程并优雅关闭旧进程
无感升级本质是“双进程切换”：新版本启动就绪后，旧进程才退出。Golang 没有内置热重载，必须靠外部进程管理实现。exec.Command 是最可控的起点，但直接 cmd.Start() 后立刻 os.Exit() 会中断服务。
关键在于让新进程确认监听成功、旧进程收到信号再退出。常见错误是新进程还没 bind 成功，旧进程就关了，导致端口短暂不可用。
- 新进程启动前，用
net.Listen("tcp", addr)尝试监听，失败则退出并打印错误（避免静默失败） - 旧进程在收到
SIGUSR2后，先调用srv.Shutdown()（非srv.Close()），等待活跃连接完成或超时 - 新进程启动后，通过文件锁或临时 socket 文件通知旧进程“我已 ready”，旧进程再退出
- 避免用
syscall.Kill(PID, syscall.SIGKILL)强杀——它跳过 Shutdown，连接会被 RST
为什么不能依赖 go run 或构建脚本做升级
go run main.go 启动的是临时二进制，PID 不稳定，且无法传递 listener 文件描述符；构建脚本如 go build -o app-new && ./app-new 会导致两次编译、两次启动，中间存在竞态窗口。
真正可用的路径只有一条：预编译好新二进制（如 ./myapp-v2），旧进程用 exec.Command("./myapp-v2", os.Args[1:]...) 启动，并把当前 listener 的 Listener.Addr() 和 ln.(*net.TCPListener).File() 传给新进程。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
ln.(*net.TCPListener).File()获取底层 fd，再通过cmd.ExtraFiles = []*os.File{file}传入新进程 - 新进程启动后，用
os.NewFile(uintptr(fd), "listener")恢复 listener，避免重复 bind - 旧进程不能关闭这个 fd，否则新进程的 listener 会失效——这是最容易踩的坑
SIGUSR2 信号处理中常见的阻塞与超时陷阱
很多实现把 signal.Notify(c, syscall.SIGUSR2) 放在主 goroutine，然后同步执行启动逻辑，结果整个 HTTP server 阻塞住，无法响应健康检查或活跃请求。
正确做法是：信号接收和升级流程必须异步，且要有明确超时控制。
- 收到
SIGUSR2后，立即 spawn goroutine 执行升级，主循环继续处理请求 - 升级 goroutine 内部要设总超时（比如 30 秒），包含启动新进程、等待 ready、Shutdown 超时三阶段
- Shutdown 超时建议设为 5–10 秒，太短会强制断连，太长影响升级速度
- 别用
time.Sleep等新进程——改用 channel + context.WithTimeout 等待 ready 信号
生产环境必须验证的三个状态点
上线前不验证这三点，升级大概率出问题：新进程是否真在监听、旧进程是否真释放了端口、活跃连接是否被正常 drain。
最简单的验证方式是：升级前后分别跑 lsof -i :8080 和 ss -tuln | grep :8080，确认 PID 变更且旧 PID 不再持有端口；用 curl -v http://localhost:8080/health 看是否始终返回 200；用 ab -n 1000 -c 100 http://localhost:8080/ 测试过程中是否有 502 或连接拒绝。
- 新进程启动后，必须主动调用
http.Get("http://localhost:8080/health")自检，失败则退出并 log 错误 - 旧进程 Shutdown 完成后，要写一个
upgrade.done文件或发 UDP 包到监控端，供运维确认 - 所有日志必须带
pid和version字段，否则无法区分是哪个进程打的日志
跨版本升级时，listener fd 传递和 Shutdown 行为差异极大，哪怕只是 Go 小版本升级（如 1.21 → 1.22），也要在 staging 环境完整走一遍流程。fd 传递失败不会 panic，只会 bind 失败静默退出——这是最隐蔽的故障点。
