Go语言无真正热更新能力，plugin仅支持Linux/macOS且不可卸载重载，fsnotify+go run仅为开发调试方案，生产环境须用平滑重启或配置热更。
Go 语言没有真正的代码热更新能力，plugin 和外部进程方案都不是运行时 reload，而是进程替换或模块加载——且 plugin 在生产环境基本不可用。
为什么 plugin 不是热更新
Go 的 plugin 包从 1.8 引入，但它是实验性特性，有硬性限制：
- 仅支持 Linux/macOS，Windows 完全不支持
- 只能
Open，不能Close或重载；一旦加载，符号和内存状态就固定了 - 要求主程序与插件使用完全一致的 Go 版本、
GOOS/GOARCH、编译参数（如-buildmode=plugin），稍有差异就plugin.Open: failed to load plugin - 插件中无法引用主程序的类型（除非用
interface{}+ 反射绕过，但失去类型安全） - 修改插件后必须重启主程序才能生效——这已经不是“热”了
你看到的 plugin.Lookup("Handler") 调用，只是在运行时查一个已加载的函数指针，不是动态编译+注入+替换。它更像 C 的 dlopen，不是 Java 的类重定义。
fsnotify + go run 只适合本地开发
这是新手最常试的组合，但本质是「反复启动新进程」，问题集中爆发：
立即学习“go语言免费学习笔记（深入）”；
- 每次保存都执行
exec.Command("go", "run", "main.go")，老进程还在跑，连接不断开，新请求打到新进程，旧请求卡在老进程——双写日志、状态不一致 -
go run启动慢（尤其依赖多时），连按两次保存，控制台堆满重复输出 -
fsnotify对 IDE 临时文件（如main.go~、.#main.go）敏感，频繁误触发 - 环境变量（如
PORT=3000）、信号（如SIGUSR2）不会自动透传，得手动拼进cmd.Env - Windows 下路径分隔符（
\vs/）容易出错，watcher.Add("main.go")可能失败
它唯一价值是：改完代码立刻看效果。别把它当生产方案。
生产可用的只有平滑重启（graceful restart）
真正零中断的方案，核心是让新二进制继承老进程的监听 socket 文件描述符，而不是抢端口。关键点：
- 必须用
net.ListenConfig{Control: ...}显式传递 fd，不能各自调用net.Listen——否则必然address already in use - 新进程启动后，需用
os.NewFile(fd, "")恢复 listener，再转成net.Listener - 老进程收到信号（如
SIGHUP或SIGUSR2）后，停止接受新连接，但继续处理已有请求，几秒后退出 - 推荐直接用成熟库：
github.com/freddierice/overseer（轻量）、github.com/mailgun/oxy/restart（HTTP 专用）、或endless（已停更但逻辑清晰） - 如果你用
gin或echo，确保没封装死http.Server——要能拿到*http.Server实例，传给gracehttp.Serve或类似封装
示例中常见的 cmd.ExtraFiles = []*os.File{f} 是关键，它把 listener 的 fd 传给子进程；但若你漏掉 syscall.Unshare 或没设 SO_REUSEPORT（Linux），新进程可能无法绑定成功。
游戏服务端的配置热更 ≠ 代码热更
游戏场景下所谓“热更新”，99% 是配置热更（数值表、掉落规则、技能参数），不是代码逻辑替换：
- 配置必须用不可变结构体 +
atomic.Value.Store替换指针，禁止直接改字段 - 读取配置必须通过访问器函数（如
GetSkillConfig(id)），每次调用都Load()最新指针，避免 goroutine 持有旧引用 - 大配置表要分片（
drop_001.json,drop_002.json），只重载变更项，避免主线程卡顿 - 状态迁移靠快照 + 回放，不是靠“热替换”——玩家在线数据必须序列化落盘，新进程启动后校验兼容性再加载
- 别碰
plugin做游戏逻辑热更，也别信“内存补丁”工具；真要动态逻辑，用 Lua/WASM 沙箱，Go 只做宿主调度
最易被忽略的一点：所有热更方案的前提，是业务逻辑本身无状态或状态可迁移。如果代码里藏着全局 map、未导出字段、闭包捕获的局部变量，再好的热更机制也会失效。
