Go服务平滑重启必须协同信号协调、文件描述符继承和上下文传播三者，仅调http.Server.Shutdown()会导致连接中断、address already in use或502错误，因其不传递socket fd、不启动新进程、不释放端口。
Go 项目无法靠 http.Server.Shutdown() 单独实现平滑重启——它不传 socket fd、不启新进程、不释放端口，直接调用只会触发 address already in use 或客户端 502 错误。真正在生产可用的流程，必须同时满足信号协调、文件描述符继承、上下文传播三者协同。
为什么不能只写 server.Shutdown(ctx) 就上线
常见错误是把 Shutdown() 当成“热重启入口”，结果服务中断、curl: (7) Failed to connect、监控里 5xx 突增。
-
Shutdown()只做两件事：停止Accept()新连接、等待已有请求自然返回；它不监听任何信号，也不启动子进程 - 旧进程调完
Shutdown()后若立刻os.Exit(0)，正在写的响应体可能被截断，客户端收到connection reset by peer - 新进程若没复用 fd，直接
net.Listen(":8080")必然报bind: address already in use，因为旧进程的 listener 还在 TIME_WAIT 状态或未完全关闭
Linux 下必须用 ExtraFiles 传递 listener fd
跨进程复用监听 socket 的唯一可靠方式，是父进程显式提取 fd 并通过 exec.Cmd.ExtraFiles 传给子进程——不是环境变量、不是临时文件、不是 os.Stdin.Fd()。
- 父进程拿到 listener 后，调
ln.(*net.TCPListener).File()得到*os.File，其Fd()通常是 3（因 0/1/2 被 stdin/stdout/stderr 占用） - 启动子进程时，设
cmd.ExtraFiles = []*os.File{file}；子进程启动后第一件事：用os.NewFile(3, "")恢复句柄，再转成net.Listener：net.FileListener(file) -
http.Server.Addr必须设为空字符串""，否则server.Serve(ln)会尝试重新bind，触发冲突 - 务必验证
fileListener.Addr().String()是否与原始地址一致；原始监听用":8080"时，复原后可能变成"127.0.0.1:34567"，需手动校准
Kubernetes 场景下别自己 fork 子进程
容器内进程几乎从不等于 PID 1。kill -USR2 $PID 极大概率被 sh 或 init 拦截，子进程拿不到 fd，net.FileListener() 直接返回 invalid argument。
立即学习“go语言免费学习笔记（深入）”；
- 硬编码自 fork 在 K8s 中基本不可用；正确做法是更新
Deployment.spec.template，配合preStop生命周期钩子发SIGTERM给主进程（用于优雅关闭），而非SIGUSR2 - 若需配置热重载，应走
ConfigMap+fsnotify，而非进程级重启；代码热更新在 Go 中本就不安全（函数指针、全局状态、goroutine 生命周期不可控） - 真正需要平滑重启的场景，往往出现在裸机部署、边缘节点或无编排器的微服务网关中；此时才需手写 SIGUSR2 处理逻辑，且必须启用
SO_REUSEPORT（Linux）或SO_REUSEADDR（macOS/BSD）
最易被忽略的一点：子进程恢复 listener 后，必须确保父进程已调过 ln.Close() 或至少已退出 Accept() 循环，否则新进程的 Accept() 可能阻塞或抢不到连接；这个时序依赖信号收发与进程启动的毫秒级协调，没有中间件兜底，只能靠日志和 lsof -i :8080 实时验证 fd 归属。
