Go微服务滚动更新依赖Kubernetes调度器拉起新进程、进程间监听器传递及旧进程优雅退出协同完成，核心是信号处理、文件描述符传递和http.Server.Shutdown()的正确使用。
Go 微服务滚动更新不是靠 Go 自己“热替换”，而是靠外部调度器（如 Kubernetes）拉起新进程 + 进程间监听器传递 + 旧进程优雅退出三者协同完成的。核心不在代码多酷，而在信号、FD、Shutdown 三个环节是否严丝合缝。
如何用 http.Server.Shutdown() 实现优雅终止
这是滚动更新中唯一必须由 Go 程序自己做对的事：收到 SIGTERM 后停止收新请求，但不杀正在处理的连接。
-
Shutdown()不会自动关闭数据库连接、日志句柄或长轮询 goroutine——这些得你手动加在defer或退出前调用，比如db.Close()、log.Sync() - 超时时间别设太短；Kubernetes 默认
terminationGracePeriodSeconds: 30，你的context.WithTimeout至少留 25 秒，否则可能强制 kill 导致请求中断 - 别在
Shutdown()前调用listener.Close()——它会让server.Serve()立即返回，但连接还在飞，容易丢请求
为什么不能只靠 SIGHUP 或自己 fork() 新进程
Linux 下 Go 进程无法通过 fork() 复制监听 socket，因为 net.Listener 是封装了文件描述符的结构体，子进程没权限复用父进程的 FD，更没法继承 TCP 全连接队列。
-
SIGHUP在容器里通常被 shell 拦截，除非你的 Go 进程是 PID 1（即用ENTRYPOINT ["./app"]而非ENTRYPOINT ["sh", "-c", "./app"]） - 真正可行的是
SIGUSR2+listener.(*net.TCPListener).File()+os.NewFile()+net.FileListener()这套 FD 传递链，但仅适用于单机场景；K8s 中完全不需要手写这套逻辑 - 第三方 graceful 库（如
tylerb/graceful）已归档，且会和你自己写的信号处理冲突，推荐直接用标准库 + 手动管理 listener
Kubernetes 中滚动更新失败的三大隐形原因
90% 的“滚动更新卡住”或“流量中断”问题，其实跟 Go 代码无关，而是部署层配置没对齐。
立即学习“go语言免费学习笔记（深入）”；
-
readinessProbe返回 200 但实际还没 ready：比如/health只检查进程存活，没连 DB 或依赖服务——结果新 Pod 被标记就绪，流量进来就 panic -
maxUnavailable: 0配了，但没配minReadySeconds，导致新 Pod 就绪后立刻被当“可用”切流，而它内部 gRPC 客户端、缓存预热还没做完 - 镜像更新没改
PodTemplateSpec的任何字段（比如只改了注释），K8s 认为模板没变，不会触发滚动更新——务必改image或加个带时间戳的 annotation：last-updated: "2026-01-27T20:51:00Z"
最容易被忽略的一点：滚动更新不是“升级完就结束了”。你要验证的不是新 Pod 起来了，而是老连接是否真处理完了、日志里有没有 http: Server closed、DB 连接池是否清空、Prometheus metrics 是否显示旧实例的请求量归零——这些才是平滑的证据。
