plugin.Open 加载失败：找不到 .so 文件或符号
Go 的 plugin.Open 只能加载后缀为 .so 的共享对象，且该文件必须由与主程序**完全相同版本、GOOS/GOARCH、CGO_ENABLED 状态**的 Go 编译器生成。常见报错是 "plugin.Open: plugin was built with a different version of package …" 或 "no such file or directory"。
- 确保插件编译时用
go build -buildmode=plugin -o plugin.so plugin.go，不能用go run或普通go build - 主程序和插件必须使用同一份
GOROOT和GOVERSION；交叉编译（如 macOS 编译 Linux 插件）直接失败 -
plugin.Open接收的是**绝对路径或相对于当前工作目录的路径**，不是import path；建议用filepath.Abs校验 - Linux 下若提示
"cannot allocate memory"，大概率是插件依赖了主程序未链接的 C 库（比如插件用了cgo但主程序没开CGO_ENABLED=1）
Symbol 查找失败：类型不匹配或未导出
通过 plug.Lookup("MyFunc") 拿到的是 plugin.Symbol，本质是 interface{}，必须显式类型断言。一旦断言失败，运行时报 "interface conversion: interface {} is nil, not func()"。
- 插件中要导出的函数、变量必须首字母大写（即包级公开），且签名需**字节级一致**：比如主程序期望
func(string) error，插件里写成func(string) *errors.errorString就会断言失败 - 如果插件导出了结构体，主程序无法直接使用其字段或方法——因为两个二进制的类型信息不互通；安全做法是只导出函数，让函数返回统一接口（如
type Plugin interface { Run() error }） - 避免在插件中使用
unsafe.Pointer或反射操作主程序的私有类型，会触发 panic 或内存错误
插件热更新时 panic：全局状态冲突或资源未释放
Go plugin 不支持真正的“卸载”，plugin.Close() 仅关闭句柄，已加载的代码和全局变量（如 init() 中注册的 handler、打开的文件描述符、启动的 goroutine）仍驻留内存。反复 Open + Close 极易导致资源泄漏或竞态。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 插件内部不要在
init()里做不可逆初始化（如http.HandleFunc、log.SetOutput）；改用显式Setup()函数由主程序调用 - 若插件启了 goroutine，必须提供
Shutdown()并在plugin.Close()前手动调用，否则 goroutine 会持续运行并可能访问已失效的内存 - Linux 下多次加载同名插件，即使路径不同，也可能因符号表冲突导致 segfault；建议每次构建插件时加时间戳或哈希后缀（如
plugin_v1.2.3_abc123.so）
跨平台兼容性差：macOS / Windows 下基本不可用
plugin 包在 macOS 上要求 CGO_ENABLED=1 且依赖 dlopen 行为，在 Apple Silicon 上更不稳定；Windows 完全不支持（Go 官方明确标注 // +build !windows）。
立即学习“go语言免费学习笔记（深入）”；
- macOS 上若报
"dlopen: cannot load any more object with static TLS"，说明插件或其依赖的 C 库用了静态 TLS（如某些 OpenSSL 版本），无解，只能换依赖 - Windows 用户别挣扎，
plugin在那里是摆设；考虑用进程间通信（gRPC / HTTP）+ 子进程方式替代 - 即使 Linux 下可用，也仅限于同构环境：容器内运行的主程序，不能加载宿主机编译的插件（glibc 版本、musl vs glibc 差异都会崩）
真正难的不是怎么写 plugin.Open，而是怎么让主程序和插件在类型、生命周期、错误处理上达成脆弱的一致。哪怕只改一行插件代码，都得重新编译整个生态，稍不注意就掉进符号冲突或内存越界的坑里。
