不能。Go plugin不支持卸载（plugin.Close为空实现），无法原子切换或重载，仅能通过进程重启模拟；Linux下文件覆盖后仍运行旧代码，反复Open导致内存累积，且调用慢3–8倍、跨平台脆弱、ABI敏感。
plugin.Open 能否实现真正的热更新
不能。go 的 plugin 包不支持卸载，plugin.close() 是空实现（官方文档明确标注 “not implemented”）。所谓“重载”，只能靠进程重启或 fork 子进程模拟——这不是热更新，是进程替换。
常见错误现象：plugin.Open("plugin.so") 成功，但后续调用时行为没变，实际是因为 Linux 下已加载的插件仍运行旧代码（即使文件被覆盖）；Windows 下甚至因文件锁打不开新版本。
- 反复
plugin.Open同一个文件，符号表和类型信息不会释放，内存持续累积 - 没有原子切换机制：A 插件正在执行中，无法安全切到 B；只能等它自然结束，或发信号中断（无标准方式）
- 更新频率必须极低（如每天一次），且能容忍短暂不可用——Web 服务、API 网关、实时流处理等场景基本不适用
为什么 plugin.Lookup 经常返回 nil
不是路径错，也不是文件没生成，而是导出规则没满足。纯 Go 插件只认包级首字母大写的符号，且不能被编译器内联。
常见错误现象：sym.Lookup("MyFunc") 返回 nil，但函数明明写了且首字母大写。
- 插件源码包名不是
main：编译会报-buildmode=plugin requires exactly one main package - 主程序和插件用了不同 Go 版本、不同
GOOS/GOARCH，或一方启用cgo另一方没启 - 插件里引用了主程序定义的 struct/interface 类型（哪怕只是参数或返回值），
Lookup会失败或 panic - 若需传自定义类型，必须定义在双方都 import 的独立共享包中，不能放在主程序或插件内部
性能开销到底有多大
实测下来，plugin.Open + sym.Lookup + 调用，单次比直接调用慢 3–8 倍。这不是 GC 或内存问题，而是 Go 运行时对插件函数的封装层导致的必然开销。
主要卡点在反射调用和符号查找，函数本身逻辑耗时占比反而很小。
- 调用链路长：符号查找 → 类型断言 → 反射调用 → 实际函数入口，每步都有 runtime 开销
- CPU 缓存不友好：插件代码与主程序内存布局分离，无法享受连续指令缓存
- pprof / trace 链路断裂：插件内函数调用栈不完整，调试和性能分析困难
- embed + 重新编译反而更快：函数是静态链接，零反射，缓存局部性好，全链路可观测
跨平台和依赖兼容有多脆弱
官方只明确支持 Linux、FreeBSD、macOS；Windows 官方不支持（issue #19282 仍 open），也无计划支持。即使在 macOS 上，也有符号冲突、dylib 加载失败等偶发问题。
依赖层面更敏感：主程序和插件只要共用一个第三方库，就必须版本完全一致；任一方用了 vendor，就得基于同一份 vendor 目录构建。
- 不同 Go 版本之间 ABI 不兼容，哪怕只是小版本升级（如 1.22.3 → 1.22.4）也可能导致
plugin.Open失败 - 插件里不能使用
net/http.DefaultClient这类全局变量——主程序和插件各自初始化一份，行为可能不一致 - 日志、指标、配置等基础设施若未通过接口注入，插件会绕过主程序的统一治理能力
真正落地时，最常被忽略的是：**插件不是功能模块的简单拆分，而是两个独立二进制之间的 ABI 协议**。它要求版本、构建环境、依赖树、符号导出方式全部对齐，稍有偏差就静默失败。多数所谓“热更新”需求，用 embed + 外部配置驱动分支 + 进程优雅重启，反而更稳、更快、更易 debug。
