go plugin.open仅支持linux，需同版本/平台/禁cgo构建，用绝对路径加载；插件与主程序类型隔离，通信靠共享接口或序列化；无卸载机制，init重复执行。
plugin.Open 加载失败：找不到 .so 文件或 symbol
Go 的 plugin.Open 不是通用动态库加载器，它只认 Go 编译器生成的、带完整符号表和类型信息的 .so 文件。常见报错如 "plugin.Open: plugin was built with a different version of package xxx" 或 "symbol not found"，本质都是 ABI 不兼容。
- 确保插件和主程序用**完全相同的 Go 版本、GOOS/GOARCH、且都禁用 CGO**（
CGO_ENABLED=0），否则运行时类型反射会失败 -
.so必须由go build -buildmode=plugin构建，不能用-ldflags="-s -w"去符号——这会删掉 plugin 运行必需的类型元数据 - 路径必须是绝对路径，
plugin.Open("foo.so")会按相对路径找，通常失败；改用plugin.Open("/abs/path/to/foo.so")
插件里无法调用主程序定义的函数或类型
plugin 和主程序之间没有共享内存空间，类型系统完全隔离。即使两个包里定义了结构体字段一模一样，main.Foo 和 plugin.Foo 在运行时是不同类型，强制转换会 panic。
- 跨边界通信只能靠 **interface{} + 显式约定方法签名**，比如插件导出一个
func() PluginInterface，主程序定义type PluginInterface interface { Do() error }，并确保双方都 import 同一份接口定义（通常放在独立的公共 module 中） - 避免在插件中直接引用主程序的包路径（如
import "myapp/config"），这会导致构建失败或类型冲突 - 如果必须传结构体数据，用 JSON / gob 序列化后再过界，别碰指针或未导出字段
Linux 下能跑，macOS 或 Windows 直接不支持
Go 官方明确标注：plugin 包仅在 Linux 上保证可用。macOS 对 dlopen 的限制极严（尤其 SIP 开启时），Windows 根本没实现 plugin 支持。
- CI/CD 流水线若混用多平台，
plugin相关代码必须加// +build linux构建约束，否则 macOS 构建直接报错 - 不要依赖
runtime.GOOS == "linux"做运行时判断——编译阶段就失败，根本到不了运行时 - 生产环境若需跨平台热加载，得换方案：比如用子进程 + gRPC / HTTP 通信，或用 WASM（TinyGo + wasmtime）替代
插件 reload 后全局变量/初始化逻辑重复执行
每次 plugin.Open 都会重新执行插件包的 init() 函数，且插件内全局变量（包括 sync.Once、loggers、DB 连接池等）不会自动复用或清理。
立即学习“go语言免费学习笔记（深入）”；
- 插件内部避免在
init()里做不可重入操作（如打开文件、注册 handler、启动 goroutine） - 如果需要单例资源，用 lazy-init +
sync.Once封装，但注意：主程序重启插件后，sync.Once状态是新的，不会继承上次的 done 标志 - 插件卸载不可逆——Go 没有
plugin.Close，so 文件句柄会一直占着，频繁 reload 可能导致 fd 耗尽
真正麻烦的不是怎么写 plugin，而是怎么设计边界：哪些逻辑放进去、哪些留在主程序、错误怎么透出、版本怎么对齐。这些地方一旦松动，调试成本远高于静态链接。
