插件接口必须定义在独立包中，主程序和插件共同依赖该包以避免符号不一致导致加载失败；Windows 不支持 plugin 包，Linux 生产环境也应慎用，推荐用子进程 + gRPC 实现隔离、跨平台、容错的插件机制。
插件接口必须定义在独立包里，不能和主程序共用 struct
Go 的 plugin 包在运行时加载插件时，会做严格的符号一致性校验。如果插件代码里直接引用了主程序定义的 struct 或 interface{}（哪怕名字、字段完全一样），plugin.Open() 会 panic 报 "incompatible plugin" —— 这不是类型转换失败，而是链接期就拒绝加载。
正确做法是把所有插件契约提前抽到一个单独的模块，比如 github.com/yourorg/pluginapi，主程序和所有插件都依赖它：
package pluginapi
type Plugin interface {
Name() string
Start() error
Stop() error
Version() string
}
type Config struct {
Addr string `json:"addr"`
Timeout int `json:"timeout"`
}
- 主程序只 import
github.com/yourorg/pluginapi，不暴露任何内部类型 - 每个插件模块也只 import 这个包，实现
Plugin接口 - 配置、输入输出结构体也统一走这个包，避免 JSON 序列化时字段名/标签不一致
Windows 下别碰 plugin 包，生产环境 Linux 也要谨慎
plugin 包在 Windows 上直接不可用：plugin.Open() 会 panic 报 "plugin: not implemented on windows"。这不是编译问题，是 Go runtime 层硬性禁用。
即使在 Linux 上，它也有三个致命限制：
立即学习“go语言免费学习笔记（深入）”；
- 插件和主程序必须用完全相同的 Go 版本、
-gcflags、CGO_ENABLED 状态编译，否则加载失败 - 插件无法调用主程序的任何函数或访问其变量（只能单向通信：主程序调插件）
- 插件崩溃会导致整个进程 panic，没有隔离机制
所以除非你明确只在 Linux 开发机上做快速验证，否则不要把它当生产级插件方案。
用子进程 + gRPC 替代 plugin 是更可靠的选择
真正可落地的“插件”，是把每个模块做成独立可执行文件，主程序用 os/exec.Command 启动，通过 gRPC 或 HTTP 通信。这样能天然解决跨平台、版本隔离、崩溃防护等问题。
关键设计点：
- 约定插件启动参数，如
--grpc-addr=:9001，主程序等待该端口 ready 后再发请求 - 插件进程启动后主动注册健康检查端点（如
/health），主程序定期探测 - 错误分层：子进程启动失败 → “插件未就绪”；gRPC 调用超时 → “响应延迟”；返回 status.Code == InvalidArgument → “参数错误”
- 所有插件二进制放在
plugins/目录下，主程序扫描并按需启动
微内核的“核心”其实就三件事：加载、路由、生命周期
所谓微内核，并不需要复杂框架。它的核心逻辑往往只有几十行代码：
type Kernel struct {
plugins map[string]*PluginInstance
}
func (k *Kernel) Load(name string, path string) error {
cmd := exec.Command(path, "--grpc-addr=:0")
cmd.Start()
// 等待插件监听端口并返回真实 addr
addr := waitForGRPCAddr(cmd.Process.Pid)
k.plugins[name] = &PluginInstance{
Cmd: cmd,
Conn: grpc.Dial(addr, ...),
}
return nil
}
func (k *Kernel) Route(req *Request) (*Response, error) {
plugin := k.plugins[req.Module]
return plugin.Client.Handle(context.Background(), req)
}
真正的复杂度不在加载机制，而在于插件之间的协作契约：比如日志怎么透传、上下文怎么传播、配置怎么同步、错误码怎么对齐。这些细节一旦没对齐，后期排查成本远高于换一种加载方式。
