go plugin机制不支持热更新，所谓“reload”实为进程替换；plugin.close为空实现，无法卸载，plugin.open+lookup调用比直接调用慢3–8倍，主因是反射封装和符号查找开销。
Go 的 plugin 机制不支持热更新，所谓“reload”只是进程替换，不是代码热替换。 它能做的只有加载、调用、然后永远留着——plugin.Close() 是空实现，无法卸载，也无法安全覆盖重载。
plugin.Open 和 plugin.Lookup 的实际调用流程
加载插件必须走两步：先 plugin.Open() 打开 .so 文件，再用 plugin.Lookup() 查符号。中间没有缓存、不自动解析依赖、也不校验类型兼容性。
-
plugin.Open()成功只表示文件可读 + 格式合法 + Go 版本/GOOS/GOARCH/cgo 开关完全匹配；失败常见原因是版本不一致或混用了 cgo -
plugin.Lookup("MyFunc")返回nil通常是因为函数没导出（首字母小写）、被编译器内联了、或参数含主程序私有类型（比如插件里用了main.MyStruct） - 查到符号后必须显式类型断言，例如
f.(func(string) int)；断言失败会 panic，且无法在运行时获知签名是否匹配
为什么 plugin.Lookup 调用比直接调用慢 3–8 倍
性能瓶颈不在 IO 或内存，而在 Go 运行时对插件符号的封装层：每次调用都要走反射路径 + 符号表查找 + 类型检查 + 接口转换。
- 不是 GC 拖累，也不是 GC 频繁触发，是每次调用都绕不开的固定开销
- 即使把
plugin.Symbol缓存下来，后续调用仍比直接函数调用慢，因为底层仍是reflect.Call封装 - 如果插件函数本身很轻量（比如只返回常量），这个倍数会更明显；重计算型函数则相对掩盖部分开销
所谓“热更新”在 plugin 场景下只能靠进程级替换
你不能 plugin.Open() 同名新文件来覆盖旧插件，也不能 Close() 后重新 Open() —— 这会导致符号地址冲突、内存泄漏，甚至 runtime crash。
- 可行做法只有：启动子进程加载新版插件，通过 socket / pipe / shared memory 把状态传过去，再让父进程退出
- 信号如
SIGUSR2可用于触发 fork，但要注意文件描述符继承、监听端口复用、以及旧连接 graceful shutdown - 插件更新 ≠ 配置更新：
viper.WatchConfig()能安全重读配置，但plugin没有等价机制；别把两者混淆使用
真正容易被忽略的是：插件和主程序之间类型隔离是硬性限制。哪怕只差一个字段名、一个 tag、甚至一个未导出字段顺序不同，plugin.Lookup() 都可能静默失败或 panic。这不是 bug，是 Go 类型系统的必然结果——它不提供跨插件的类型兼容性协商。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
