go无法实现真正热更新，仅支持平滑重启；核心在于监听器复用（sigusr2+net.filelistener传递fd）、外部进程调度与部署层配合（如k8s readinessprobe、prestophook等），而非语言本身。
做不到真正意义上的“热更新”，只能做平滑重启；核心流量不中断的关键不是 Go 本身，而是监听器复用 + 外部进程调度 + 部署层配合。
为什么 go run 或 fsnotify 不适合线上核心模块
它们只是反复启动新进程，老进程的 net.Listener、活跃连接、goroutine 全部丢失，HTTP 请求直接 reset。常见现象包括：
- 用户看到
connection reset或超时（502/504） - IDE 保存临时文件（如
main.go~）触发误重启 -
go run启动慢，依赖多时卡住 2–3 秒，连续改两行就堆积一堆僵尸进程 - 原进程的
PORT、ENV、SIGUSR2等信号无法透传给新实例
必须用 SIGUSR2 + net.FileListener 传递监听器
这是 Linux 下唯一能复用 TCP socket 的方式，本质是把监听器的文件描述符（FD）从老进程传给新进程。关键点：
- 老进程收到
SIGUSR2后调用listener.(*net.TCPListener).File()获取 FD - 用
exec.Command启动新进程，并通过ExtraFiles把 FD 传过去（不能写文件再读，有竞态） - 新进程用
os.NewFile(fd, "")→net.FileListener(fdFile)恢复监听器 - 老进程必须调用
server.Shutdown()等待活跃请求结束，再退出（不能直接os.Exit）
示例片段（仅核心逻辑）：
fd, _ := listener.(*net.TCPListener).File()
cmd := exec.Command(os.Args[0], os.Args[1:]...)
cmd.ExtraFiles = []*os.File{fd}
cmd.Start()
// 老进程继续 Serve() 直到 Shutdown 完成
Kubernetes 场景下必须配齐三件套
单靠 Go 代码写得再好也没用，流量切走前新 Pod 必须已就绪：
-
readinessProbe必须检查监听器是否 bind 成功（比如 HTTP GET /health 返回 200） -
rollingUpdate.maxSurge: 1+maxUnavailable: 0，确保旧 Pod 不先退 -
preStopHook发送kill -USR2 $PID，且容器内进程必须是 PID 1（避免被sh -c包裹导致信号屏蔽）
漏掉任意一项，就会出现“新 Pod 已上线但没监听”或“老 Pod 被强杀导致连接中断”。
插件机制（plugin）只适用于极少数场景
plugin 包要求目标 SO 文件与主程序用完全相同的 Go 版本、构建参数（-buildmode=plugin），且不支持跨平台、不支持 Windows、不支持 CGO 混合编译。实际问题包括：
- 更新一个 handler 函数，要重新 build 整个 plugin.so，和重启没本质区别
- 插件里 panic 会 crash 主进程，无法隔离错误域
- 无法热替换全局变量、init 函数、HTTP middleware 链
- 生产环境几乎没人用——Kubernetes 原生不支持 runtime 加载 SO
真要动态加载逻辑，不如用 gRPC 插件服务或 Lua 脚本引擎，别硬啃 plugin。
最易被忽略的是：老进程 Shutdown() 的 timeout 设置和反向代理的超时配置必须对齐。比如 Nginx 的 proxy_read_timeout 设为 30s，Go 的 Shutdown 就不能只等 5s，否则连接会被代理提前断开。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
