go原生plugin包不支持热更新，plugin.close为空实现，重复open同名插件会崩溃；真正可行的是go-plugin框架，通过子进程+grpc+状态迁移实现零停机替换。
plugin.Open 和 plugin.Lookup 无法热更新，别试了
Go 原生 plugin 包不支持热更新——plugin.Close() 是空实现，调用后插件符号仍驻留内存；plugin.Open() 同名文件重复加载会触发 runtime crash；所谓“重载”只是进程重启的障眼法。你不能靠它实现运行时模块替换，强行这么做只会遇到符号冲突、内存泄漏或 panic。
真正能热更新的只有 go-plugin（HashiCorp）
它不是 Go 标准库插件，而是基于子进程 + gRPC 的跨进程通信框架。热更新靠的是：启动新插件进程、迁移状态（如 socket fd）、优雅关闭旧进程。关键点包括：
-
HandshakeConfig.ProtocolVersion必须随插件版本递增，否则主进程拒绝连接新插件 - 必须用
ReattachConfig配合 PID + Stdio 文件描述符，才能让主进程“找回”正在运行的插件进程 - 插件接口定义（如
Greeter）必须在主程序和插件中完全一致：字段顺序、未导出字段、struct tag 全部匹配，否则plugin.Serve()启动即失败 - 日志、panic 捕获、信号转发（如
SIGTERM）需显式配置，否则插件崩溃主进程无感知
热更新时最容易被忽略的三个类型兼容性陷阱
即使编译通过，插件与主程序之间类型不兼容也会导致静默失败或运行时 panic：
- 主程序定义的
type Config struct{ Port int }和插件里一模一样的定义，只要包路径不同（比如main.Configvsplugin.Config），plugin.Lookup()返回的 symbol 就无法断言成功 - 结构体字段加了
json:"port"tag，但主程序没加，或大小写不一致，gRPC 序列化时字段丢失，表现为字段值为零值 - 函数签名含 interface 类型（如
func(context.Context, io.Reader) error），而该 interface 在主程序和插件中是不同包下的同名类型，断言必失败
别把配置热更新和插件热更新混为一谈
viper.WatchConfig() 或 fsnotify 监听的是文件内容变更，它只负责通知“配置变了”，不涉及任何代码加载；而插件热更新是加载全新二进制逻辑。两者生命周期、错误域、回滚方式完全不同：
- 改一个
log_level配置项，可以立即生效；但换一个插件版本，必须重建所有依赖该插件的 service 实例、重连 DB、重绑监听端口 - 配置加载失败可降级用旧值；插件加载失败则整个功能模块不可用，没有“fallback 插件”机制
- 配置变更通常无状态；插件更新必须处理状态迁移——比如 HTTP 连接池里的活跃连接怎么移交、gRPC 流如何续传
最常被绕开又最致命的问题：你以为 reload 了插件，其实只是 reload 了配置；或者以为 reload 了配置，结果偷偷替换了插件二进制，却忘了清理旧 goroutine 和资源引用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
