Go Plugin不可用于生产微内核架构，因其仅支持Linux/FreeBSD，要求主程序与插件在Go版本、构建参数（含-buildmode=plugin）、CGO状态、符号导出规则等方面字节级一致，且不支持热重载或跨CGO调用。
Go Plugin 不能用于生产环境的微内核架构 —— 它仅支持 Linux/FreeBSD，要求主程序与插件完全一致的 Go 版本、构建参数（包括 -buildmode=plugin）、符号导出规则，且不支持跨 CGO 边界调用或热重载。
为什么 plugin.Open() 总是报 “plugin was built with a different version of package”
这不是版本号显示不同，而是 Go 编译器把构建环境（如 GOPATH、GOEXPERIMENT、cgo 状态、-gcflags）全部编码进插件的符号哈希中。哪怕只改了一个 go build -ldflags="-s"，主程序就打不开插件。
- 必须用完全相同的
go命令构建主程序和所有插件（建议写成 Makefile 或 shell 脚本统一调用） - 插件代码里不能 import 主程序的包路径（否则隐式绑定），应定义独立接口包（如
github.com/your/app/pluginiface），由双方共同依赖 - 插件中导出的 symbol 必须是首字母大写的变量（如
var Impl pluginiface.Module = &MyPlugin{}），不能是函数或方法
如何让插件安全地注册服务而不 panic 主程序
插件加载失败、初始化 panic、类型断言失败都会导致主程序崩溃。必须用 recover() 在 plugin 加载后立即包裹初始化逻辑，且不能在插件内部做全局 init。
- 主程序中用
defer func() { _ = recover() }()包裹sym := plug.Lookup("Impl")和后续类型断言 - 插件的
Init()方法不应有副作用（如连接数据库、监听端口），而应返回一个可启动的实例，由主程序统一调度生命周期 - 推荐约定插件实现
pluginiface.Module接口，含Start() error/Stop() error/Name() string，避免反射调用任意方法
替代方案比 plugin 更实际：用子进程 + gRPC
真正需要插件热更新、语言无关、故障隔离时，plugin 是技术负债。主流做法是让每个插件为独立二进制，通过 Unix domain socket 或 localhost TCP + gRPC 通信。
- 主程序用
exec.Command启动插件进程，传入--plugin-addr=/tmp/plugin1.sock - 插件进程启动后立刻监听该地址，实现
RegisterService和HandleRequestRPC 方法 - 主程序用
grpc.DialContext连接，超时控制、重连、鉴权都可标准化处理 - 这样插件可用 Rust/Python/Go 混合编写，崩溃不影响主程序，还能用
systemd --scope控制资源
真正难的不是怎么调用 plugin.Open()，而是设计插件边界：哪些状态能共享、错误如何透出、配置如何下发、日志如何归集。这些在进程内靠 plugin 都得自己缝，而子进程模型天然分隔清楚。
