go plugin仅linux稳定可用，macos受sip限制、windows不支持；主程序与插件须完全一致的go版本、构建参数、依赖树及goroot；必须用-buildmode=plugin构建，路径为绝对路径，且需共享接口而非类型。
Go 的 plugin 包不是“通用动态库加载器”，它只在 Linux 上稳定可用；macOS 有签名和 SIP 限制，Windows 完全不支持。想靠 plugin.Open 实现跨平台热插拔，基本会失败。
plugin.Open 找不到 .so 或报 “built with a different version”
这不是路径写错，而是 Go 编译器对 ABI 兼容性做了硬校验：主程序和插件必须用完全相同的 Go 版本、GOOS/GOARCH、CGO_ENABLED 状态、go.mod 依赖树、甚至 GOROOT 路径构建。
-
plugin.Open加载失败时，90% 是因为插件用了go build（没加-buildmode=plugin）或主程序用了go run（临时构建导致模块哈希不一致） - 路径必须是绝对路径：
plugin.Open("/abs/path/to/math.so")，传"./plugins/math.so"会按当前工作目录找，极易失败 - Linux 下需确保插件是 ELF 格式、无
main函数、且未被-ldflags="-s -w"strip 符号——这会删掉类型元数据，导致Lookup失败 - macOS 用户请直接放弃：SIP + dlopen 限制 + 符号签名问题，即使加
-ldflags="-s -w"也大概率失败
plugin.Lookup 返回 nil 或类型断言 panic
Go 插件不导出类型定义，只暴露首字母大写的包级变量或函数；且符号的底层类型必须字节级一致，不是“看着像”就行。
- 插件里写了
func Add(a, b int) int，主程序却用func(int, int) int断言 → panic，因为参数名、包路径、是否指针都参与签名计算 - 插件中定义了
type Router struct{}，主程序不能用struct{}去转换 —— 即使字段一样，main.Router和plugin.Router是两个运行时类型 - 正确做法是定义共享接口（如
type Processor interface { Process() error }），放在独立pluginapi模块中，主程序和插件都 import 它 - 调试时可用
nm -gU plugin.so（macOS）或objdump -t plugin.so | grep Add（Linux）确认符号是否真实存在、名称是否带包前缀
plugin.Close 不等于卸载，热更新不可靠
plugin.Close() 只释放部分资源句柄，插件中已注册的 HTTP handler、启动的 goroutine、全局 map、文件描述符等全部残留。所谓“热更新”，其实是进程外管理的事。
- 插件里的
init()函数每次plugin.Open都会执行一次，无法重入；别在里面打开日志文件或注册全局 mux -
plugin.Close()后再调用任何该插件的Symbol，会 panic：plugin: symbol name not found - 生产环境若需热加载，应改用子进程模型：插件作为独立二进制，主程序用
os/exec.Command启动，通过 HTTP / gRPC 通信，崩溃可自动重启 - 如果非要用 plugin，务必确保插件逻辑幂等，并显式提供
Start()/Stop()接口，由主程序控制生命周期
真正难的不是怎么写 plugin.Open，而是怎么让主程序和插件在编译期就“严丝合缝”——版本、构建参数、模块路径、甚至 GOPATH，差一点都会在运行时报错，且错误信息极其模糊。别把它当通用插件机制用，它本质是个 Linux 测试工具。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
