plugin调用比直接调用慢3–8倍，主因是反射和符号查找开销；不支持卸载与原子热更新，仅适用于isv扩展或特殊隔离场景，embed+重启更可控安全。
plugin 加载后调用函数比直接调用慢多少
实测下来，plugin.Open 后通过 sym.Lookup 获取函数再调用，单次开销比直接调用高 3–8 倍，主要卡在反射调用和符号查找上。这不是 GC 或内存问题，而是 Go 运行时对插件函数的封装层导致的必然开销。
常见错误现象：plugin.Open 成功，但 sym.Lookup("MyFunc") 返回 nil，实际是因为导出函数没加首字母大写，或没用 //export 注释（仅 CGO 场景需要）；纯 Go 插件只需确保函数是包级导出（首字母大写）且未被内联。
- 必须用
go build -buildmode=plugin编译插件，普通.so不兼容 - 主程序和插件必须用完全相同的 Go 版本、GOOS/GOARCH、且不能混用 cgo 开启/关闭状态
- 插件里不能引用主程序的类型（包括 struct、interface），否则
Lookup失败或 panic - 如果函数参数含自定义类型，得定义在共享的独立包中，并在主程序和插件里都 import
热更新时 reload plugin 的实际可行性
Go 的 plugin 不支持卸载，plugin.Close 是空实现（文档明确写 “not implemented”）。所谓“reload”，只能靠进程级重启或 fork 子进程模拟——这不是热更新，是进程替换。
使用场景很窄：只适合配置极简、更新频率极低（比如每天一次）、且能容忍短暂不可用的后台工具类服务。Web 服务、API 网关、实时计算流等场景基本不适用。
立即学习“go语言免费学习笔记（深入）”；
- 反复
plugin.Open同一个文件，会累积内存（符号表、类型信息不会释放） - Linux 下即使文件被覆盖重写，已加载的插件仍运行旧代码；Windows 下甚至可能因文件锁打不开新版本
- 没有原子切换机制：A 插件正在执行时，你无法安全地“切到 B”，只能等它自然结束，或发信号中断（无标准方式）
替代方案：为什么 embed + 重新编译比 plugin 更可控
对大多数所谓“热更新”需求，真正落地更稳的是：把业务逻辑写成独立包，用 embed 打进主二进制，配合外部配置驱动行为分支；更新时重新构建主程序并滚动替换。这省去了插件所有兼容性雷区。
性能对比反而更好：函数调用是直接静态链接，零反射开销；内存布局连续，CPU 缓存友好；调试、pprof、trace 全链路可见。
-
embed不增加运行时依赖，也不要求目标机器装 Go 工具链 - 若需差异化逻辑，可用
//go:buildtag 分离环境专用代码，构建时按需包含 - 想模拟“热重载”效果？用文件监听 +
exec.Command("kill", "-USR2", pid)触发主程序优雅重启，比 plugin.open 安全得多
plugin 在哪些真实场景下值得用
只有两类情况 plugin 有不可替代性：一是 ISV 提供白盒 SDK，允许客户写 Go 插件扩展（如监控采集器、日志处理器）；二是极特殊的安全沙箱需求，需严格隔离插件内存空间（虽然 Go plugin 并不提供真正的沙箱，但至少能限制符号可见性）。
容易被忽略的一点：plugin 文件本身是完整 ELF，可被 readelf -d 查看依赖，也能被 gdb 调试——但这要求主程序和插件都带 DWARF 信息，且调试器要能同时加载两者符号，实操门槛远高于常规开发。
- 插件中禁止使用
init函数做全局初始化，因为多次 Open 可能触发多次（未定义行为） -
unsafe.Pointer跨插件传递极易 crash，尤其涉及 slice 或 map 底层结构时 - GC 不会追踪插件内分配的对象是否被主程序引用，一旦插件变量逃逸到主程序，可能引发悬挂指针
