滚动更新需手动实现信号监听与socket传递；用SIGUSR2而非SIGHUP避免系统拦截；关键在fd继承、新进程就绪判断及优雅退出。
滚动更新在 Golang 微服务中不是语言内置能力，而是依赖进程管理、信号处理和部署协同实现的；直接调用 os.Exit() 或暴力杀进程必然导致请求中断，必须靠 syscall.SIGUSR2 或 SIGHUP 配合优雅退出逻辑。
Go 本身不自动处理信号升级，需手动监听并触发新进程启动 + 老进程等待退出。关键点是父子进程间通过文件描述符传递监听 socket（即 net.Listener），避免端口被抢占。
400-7654-355 net.Listen("tcp", addr) 创建 listener，并用 l.(*net.TCPListener).File() 提取底层 *os.File
syscall.SIGUSR2 后，用 exec.Command 启动新进程，同时把 *os.File 通过 ExtraFiles 传入子进程os.Args[0] 解析传入的 listenerFD（如 3），再调用 net.FileListener(os.NewFile(uintptr(fd), "")) 恢复监听package mainimport ( "net" "net/http" "os" "os/exec" "os/signal" "syscall" "time" )
func main() { l, _ := net.Listen("tcp", ":8080") srv := &http.Server{Handler: http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { w.Write([]byte("ok")) })}
go srv.Serve(l) sigChan := make(chan os.Signal, 1) signal.Notify(sigChan, syscall.SIGUSR2) for range sigChan { // 传递 listener fd 给新进程 file, _ := l.(*net.TCPListener).File() cmd := exec.Command(os.Args[0]) cmd.ExtraFiles = []*os.File{file} // 新进程通过 os.Args[1] 获取 fd 编号（如 "3"） cmd.Args = append([]string{os.Args[0], "3"}, os.Args[1:]...) cmd.Start() // 等待新进程 ready（简化为 sleep，生产应加健康探针） time.Sleep(500 * time.Millisecond) // 优雅关闭：不再接受新连接，等待活跃请求 srv.Close() os.Exit(0) }
}
为什么不能只用 SIGHUP？
SIGHUP在大多数 Linux 发行版中默认被 systemd 或 supervisord 拦截并用于重载配置，而非重启进程；若未显式配置，它可能被忽略或触发非预期行为（比如仅 reload 日志路径）。而SIGUSR2是用户自定义信号，语义清晰、干扰少，适合做“热升级”指令。
KillSignal=SIGTERM，避免 systemctl restart 直接触发 SIGKILL
supervisord，需在 [program:x] 下配置 stopsignal=TERM 和 stopsignal=USR2（注意版本支持）kill -USR2 $(pidof mysvc) 必须在容器内执行，不能靠 kubectl rollout restart 自动触发——后者本质是重建 Pod，不属于滚动更新的进程级语义真实线上故障往往不出现在代码逻辑，而卡在系统层或部署链路。
socket 文件描述符未正确继承：子进程读取 os.NewFile(uintptr(fd), "") 后未调用 SetDeadline 或 SetKeepAlive，导致连接超时或复位新进程启动失败但父进程已退出：缺少对 cmd.Start() 错误检查，也未监控子进程是否真正 bind 成功，结果出现服务空白期健康检查时间窗口太短：Kubernetes 的 readinessProbe 初始延迟（initialDelaySeconds）小于新进程加载配置+warmup 时间，导致流量被切到未就绪实例真正的滚动更新难点不在 Go 怎么写，而在信号怎么传、fd 怎么交、健康状态怎么判；漏掉任意一环，都会把“滚动”变成“中断”。
