plugin.Open只能加载Go用-buildmode=plugin编译的.so文件，要求主程序与插件完全一致：同Go版本（含patch号）、同GOOS/GOARCH、同CGO_ENABLED、同依赖版本及哈希，否则报“built with a different version of package”并panic。
Go 本身不支持像 C 那样用 dlopen 加载任意 .so 文件；唯一原生、安全、可控的动态加载方式，是用 plugin.Open() 加载由同一 Go 版本、相同构建参数编译出的 -buildmode=plugin 插件。
plugin.Open 只能加载 Go 自建插件，不是任意 .so
常见错误现象：plugin was built with a different version of package、cannot open shared object file: No such file（即使路径正确）、undefined symbol: _cgo_dummy。这些几乎都源于混淆了两种构建模式：
-
go build -buildmode=c-shared：生成供 C/Python 等外部语言调用的库，导出 C ABI 符号，不能被plugin.Open加载 -
go build -buildmode=plugin：生成 Go 运行时可解析的插件，符号按 Go 内部格式导出，仅能被同版本 Go 的plugin包加载
如果你试图用 plugin.Open("libfoo.so") 加载一个 c-shared 编译出来的文件，必定失败——这不是路径或权限问题，是根本机制不匹配。
插件必须与宿主程序“完全一致”才能加载成功
插件不是独立运行单元，它和宿主共享运行时上下文，因此对一致性要求极为苛刻：
立即学习“go语言免费学习笔记（深入）”；
- Go 版本必须完全相同（包括 patch 版本，如
1.22.5和1.22.6不兼容） -
GOOS/GOARCH必须一致（linux/amd64插件无法在linux/arm64宿主上加载） - 所有依赖包版本必须严格一致（
github.com/some/pkg v1.2.0在插件里用了 v1.3.0 就会 panic） - 宿主程序必须启用
CGO_ENABLED=1（即使没写 cgo 代码，plugin底层依赖 cgo 运行时）
实践中最常踩的坑是：本地开发用 go1.22.5 编译插件，部署到服务器却用 go1.22.6 运行宿主，结果 plugin.Open 直接 panic，且错误信息不提示具体版本差异。
插件中必须有至少一个导出符号，且类型需显式断言
插件文件（如 handler.so）若只包含未导出的函数或变量，plugin.Open 虽能打开，但后续 Lookup 会返回 nil 错误。导出规则和普通 Go 包一致：
- 函数名、变量名首字母大写（如
Process、PluginVersion） - 必须在
main包中定义（插件入口必须是package main） -
Lookup返回的是interface{}，必须手动类型断言，例如：sym.(func(string) error) - 断言失败会 panic，务必用
ok形式判断：if fn, ok := sym.(func(int) int); !ok { /* 处理类型不匹配 */ }
没有导出符号的插件，编译能过，运行时报 symbol not found，但错误发生在 Lookup 阶段，而非 Open 阶段——这点容易误判问题位置。
想加载非 Go 构建的 .so？只能靠 cgo 封装 dlopen
如果目标是加载 libcurl.so、libpq.so 或其他 C 编写的动态库，plugin 包完全无用。唯一可行路径是：
- 写一小段 C 代码，封装
dlopen/dlsym/dlclose - 通过 cgo 暴露为 Go 函数，例如：
func DLOpen(path string) (unsafe.Pointer, error) - 在 Go 中调用该封装函数，再手动处理符号查找与类型转换
这种做法绕过了 Go 的类型安全和 GC 管理，需自行确保内存生命周期（比如 C 函数返回的指针是否已释放）、线程安全（dlopen 非线程安全），以及跨平台差异（Windows 用 LoadLibrary，macOS 用 dlopen）。它不是“Go 动态加载”，而是“Go 调用 C 的动态加载能力”。
真正难的不是写几行 plugin.Open，而是让插件和宿主在构建、分发、部署全链路上保持 ABI 兼容性——版本锁死、依赖冻结、构建环境镜像化，缺一不可。一旦忽略其中任一环节，动态加载就从便利变成定时炸弹。
