go plugin 仅支持 linux/macos，要求主程序与插件完全一致的 go 版本、构建参数等；windows 不可用；plugin.open 需绝对路径和正确后缀；符号必须首字母大写且类型断言校验；不支持卸载，热更新需进程重启。
Go 的 plugin 包仅支持 Linux 和 macOS，且要求主程序与插件使用完全相同的 Go 版本、构建标签、CGO 设置和编译器参数；Windows 上根本不可用——这是绝大多数人踩坑的第一步。
plugin.Open 失败：符号未导出或路径错误
Go 插件中只有首字母大写的变量、函数、类型才能被外部加载；plugin.Open() 接收的是绝对路径（非相对路径），且文件必须是 .so 后缀（Linux）或 .dylib（macOS）。
- 确保插件源码中导出的符号是包级变量或函数，例如：
var PluginVersion = "1.0"或func Init() error { ... } - 构建插件时必须加
-buildmode=plugin，且不能启用-trimpath（否则符号路径信息丢失） - 运行时若报
plugin.Open: failed to load plugin: invalid ELF file，大概率是用了go build而非go build -buildmode=plugin - 插件文件权限需可读（
chmod +r plugin.so），且不能被 SELinux / sandbox 阻止（常见于容器或 CI 环境）
Symbol.Lookup 返回 nil：类型不匹配或未初始化
plugin.Symbol 查找成功只代表符号存在，不代表能安全调用；类型断言失败、函数签名不一致、或插件内部 panic 未暴露都会导致运行时崩溃。
- 务必用类型断言校验返回值，例如：
v, ok := sym.(func() error)，不能直接调用sym.(func() error)() - 插件中若依赖全局变量（如
http.DefaultClient）或 init 函数副作用，需确保主程序环境已就绪——插件的init()在plugin.Open时即执行 - 跨插件共享结构体需定义在主程序中并导出接口，插件内不能定义同名但不同包的 struct，否则类型不兼容
插件热更新不可行：内存与符号无法卸载
Go 的 plugin 不支持卸载（plugin.Close() 是空实现），重复 Open 同一路径会复用已有句柄；更严重的是，插件中分配的内存、注册的 HTTP handler、启动的 goroutine 全部滞留，无法清理。
- 不要试图用
Close()释放资源——它什么也不做，文档明确写 “not implemented” - 热更新只能靠进程重启，或改用外部进程方式（如 exec.Command 启子进程，通过 RPC/HTTP 通信）
- 插件中避免启动长期 goroutine 或监听端口；如有，必须提供显式
Shutdown()函数并由主程序调用
真正麻烦的不是怎么加载，而是插件生命周期管理、错误传播边界、以及调试时看不到插件 panic 的堆栈——因为 panic 发生在独立的 symbol 空间里，主程序只收到 panic: interface conversion: interface {} is nil, not func() 这类模糊提示。
