应避免使用 Go 原生 plugin 包，因其仅支持 Linux/macOS、Windows 硬性不支持，且要求主程序与插件完全一致的 Go 版本、构建参数和 CGO 状态，稍有差异即 panic；推荐采用模块依赖 + 接口契约 + 编译期集成方案，或进程隔离式 Pingo 方案，兼顾跨平台、可测试性与安全性。
Go 语言原生 plugin 包只支持 Linux/macOS，且要求主程序与插件用**完全相同的 Go 版本、构建参数、CGO 环境**编译，稍有不一致就会报 plugin was built with a different version of package。这不是“轻量级”，而是高耦合、难调试的陷阱。真正可行的轻量级插件方案，是绕过 plugin，用模块依赖 + 接口契约 + 运行时加载实现。
用 go modules 管理插件实现，而不是 .so 文件
把每个插件写成一个独立的 Go module（比如 github.com/yourorg/log-plugin），主程序通过 go.mod 声明依赖它，而不是动态 plugin.Open()。这样插件代码在编译期就集成进主程序，零运行时加载开销，也彻底避开 ABI 兼容问题。
- 插件 module 必须导出一个符合约定接口的变量，例如
var Plugin PluginInterface - 主程序定义统一接口（如
type PluginInterface interface { Init() error; Handle(data any) error }），所有插件都实现它 - 主程序启动时遍历已导入的插件变量（可通过反射或显式注册表），调用
Init()初始化
为什么不用 plugin.Open() 而选模块依赖？
plugin.Open() 在实际项目中几乎无法落地：Windows 不支持；CI/CD 构建环境和生产环境 Go 版本常有微小差异（如 1.22.4 vs 1.22.5）；交叉编译失效；go test 无法覆盖插件逻辑。而模块依赖方式下，插件就是普通 Go 包，可单元测试、可 debug、可 IDE 跳转，开发体验一致。
- 插件变更后，只需
go get github.com/yourorg/log-plugin@v1.2.0更新版本，再go build - 主程序无需解析符号表，无
p.Lookup("Handle")这类易错操作 - 插件可自由使用其他 module（如
github.com/sirupsen/logrus），不受主程序依赖约束
如何避免插件间符号冲突或初始化顺序问题
多个插件 module 都 import 同一第三方包（如 golang.org/x/net/http2）时，若版本不同，go build 会自动升级到最高兼容版本，但可能引发行为差异。关键点在于约束而非禁止：
立即学习“go语言免费学习笔记（深入）”；
- 主程序的
go.mod显式固定基础依赖版本，例如require golang.org/x/net v0.27.0 - 插件 module 的
go.mod不声明该依赖，或仅声明// indirect注释 - 禁止插件 export 全局变量（如
var Config *Config），全部通过Init(*Config)注入，隔离状态
需要进程隔离时，用 Pingo 替代 plugin 包
如果插件必须崩溃不影响主程序（比如解析不可信用户脚本），plugin 和模块依赖都不安全——它们共享同一进程内存。这时应换用 Pingo 这类外部进程方案：
- Pingo 插件是独立可执行文件，通过 Unix socket 通信，天然隔离
- 主程序只需
pingo.NewPlugin("tcp", "./plugins/json-parser")，不关心 Go 版本 - 插件可由不同语言编写（只要实现约定的 socket 协议），真正解耦
真正的轻量，不在于代码行数少，而在于部署简单、调试直接、升级可控。模块依赖方案省去了 .so 编译/路径管理/符号查找这些隐性成本，Pingo 则把复杂性推给进程边界——这两条路都比硬啃 plugin 包现实得多。
