Go 的 plugin 包仅适用于 Linux/macOS 上同版本、同构建参数、完全可控的极小范围场景，不支持热插拔、卸载及 Windows，且 plugin.Open 失败时几乎总是 panic。
go 的 plugin 包不适合生产环境插件化系统，仅限 linux/macos 上同版本、同构建参数、完全可控的极小范围场景（如 cli 工具的本地命令扩展）。 它不是“热插拔”方案，不支持卸载，不兼容 windows，且 plugin.open 失败时几乎总是 panic，而非可恢复错误。
plugin.Open 为什么总 panic？路径、版本、平台三者必须字节级对齐
报错 plugin was built with a different version of package 不是警告，是 ABI 层面拒绝加载。它意味着：主程序和插件的 Go 版本（含 patch，如 1.22.3 vs 1.22.4）、GOOS/GOARCH、CGO_ENABLED 状态、所有依赖模块的 go.sum 哈希、甚至 -gcflags 参数都必须完全一致。
- 用
filepath.Abs("myplugin.so")替代相对路径，避免os.Chdir导致加载失败 - Linux 下确保插件有可执行权限：
chmod +x myplugin.so - macOS 13+ 需临时关闭 Gatekeeper：
sudo spctl --master-disable，否则直接拒载未签名 .so - Windows 下
plugin包硬编码返回ErrNotSupported，连编译通过的 .so 也无法打开
plugin.Lookup 找不到函数？导出规则和类型签名必须严丝合缝
Lookup 返回 nil 或后续断言 panic，90% 是因为符号没导出或类型不匹配。Go 不做“语义等价”判断，只比对编译后符号表里的原始类型描述。
- 函数/变量名必须首字母大写，且**不能在
main包中定义**（go build -buildmode=plugin要求插件包名非main） - 插件中定义
func Add(a, b int) int，主程序就必须用sym.(func(int, int) int)断言——参数名、顺序、包路径、是否指针，全得一样 - 避免传自定义 struct；推荐统一导出一个变量，如
var Plugin PluginInterface，主程序只做一次sym.(PluginInterface)断言 - 调试时用
objdump -t myplugin.so | grep Add（Linux）或nm -gU myplugin.so（macOS）确认符号是否存在、是否带包前缀
插件能热更新吗？Close() 后全局状态全残留，根本不算卸载
plugin.Close() 只释放部分内部句柄，插件里启动的 goroutine、注册的 http.HandleFunc、打开的文件描述符、全局 map 缓存全部留在内存里。所谓“热更新”，实际只能靠外部进程管理（如主程序 fork 新进程 + 信号 reload）实现。
- 不要在插件
init()里注册全局单例（如log.SetOutput、修改http.DefaultServeMux） - 如果插件暴露
Start()/Stop()，主程序必须显式调用Stop()清理资源，再调用Close() -
Close()后再调用该插件任何Symbol会 panic：plugin: symbol name not found - 插件中不能引用主程序定义的 struct 类型，否则链接失败；解耦必须靠独立
pluginapi模块
真正可用的插件化，应放弃 plugin 包，改用进程间通信：把插件做成独立二进制，用 os/exec 启动，通过 stdin/stdout、HTTP 或 gRPC 通信。这种方式天然跨平台、语言无关、可隔离、可监控——而 plugin 的限制，恰恰是它被设计成“仅用于极少数受控场景”的原因。
