Go 1.16+ 的 plugin 包已被弃用，仅支持 Linux/macOS，要求主程序与插件完全相同的 Go 版本、构建参数及 GOPATH；推荐改用 HTTP+JSON 进程间通信替代。
Plugin 在 Go 1.16+ 已被标记为 deprecated
Go 官方明确不推荐在新项目中使用 plugin 包，它只支持 Linux 和 macOS，Windows 完全不可用；且要求主程序和插件必须用完全相同的 Go 版本、构建参数（包括 -buildmode=plugin）、甚至 GOPATH 环境也要一致。一旦不满足，plugin.Open 直接 panic，错误信息通常是：plugin.Open: plugin was built with a different version of package xxx。
常见踩坑点：
- 用
go build默认模式编译插件（没加-buildmode=plugin）→plugin.Open失败 - 主程序用
go run main.go启动 → 插件加载失败（必须是已编译的二进制） - 插件里用了
cgo或依赖了非标准库的包 → 构建时静默失败或运行时报符号缺失
替代方案：用 HTTP + JSON 实现热插拔逻辑
真正需要“动态加载”的场景（比如插件化 CLI 工具、规则引擎），更可靠的做法是让插件作为独立进程启动，通过本地 HTTP 接口通信。Go 自带 net/http 和 encoding/json，零依赖、跨平台、调试方便。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 插件进程监听
localhost:3001，暴露POST /eval接口接收 JSON 输入、返回 JSON 输出 - 主程序用
http.Client调用，超时设为5 * time.Second避免卡死 - 插件进程崩溃后，主程序可自动重启它（用
os/exec.Command+cmd.Start()） - 避免共享内存或复杂序列化 —— 只传简单结构体，字段类型限定为
string、int、bool、[]string等基础类型
如果非要用 Plugin（仅限 Linux/macOS 测试环境）
必须严格按以下步骤来，少一个都可能失败：
- 插件源码必须放在
$GOPATH/src下（不能是 module 路径），例如：$GOPATH/src/myplugin/main.go - 用完整 GOPATH 模式构建：
GO111MODULE=off go build -buildmode=plugin -o myplugin.so myplugin - 主程序也必须
GO111MODULE=off编译，且不能启用CGO_ENABLED=0 - 加载时路径必须是绝对路径：
p, err := plugin.Open("/abs/path/to/myplugin.so")（相对路径会报no such file） - 导出的符号必须是首字母大写的变量或函数，例如：
var RuleFunc func(string) bool，然后用p.Lookup("RuleFunc")
Plugin 的 symbol 查找失败到底错在哪
最常遇到的 plugin.Symbol: symbol not found，不是名字写错了，而是符号根本没被导出或链接进去：
- 检查插件代码里有没有实际给那个变量/函数赋值（空声明不算）
- 确保没用
init()函数触发了未定义行为（比如提前 panic）导致插件加载中断 - 用
nm -D myplugin.so | grep RuleFunc看符号是否出现在动态符号表里；如果没出现，说明编译时被优化掉了或没被引用 - 插件中不能 import 主程序的包（比如
main包里的类型），否则plugin.Open会因类型不匹配直接崩溃
真正难的从来不是怎么写 plugin.Open，而是怎么让两个独立编译过程产出的东西，在运行时还能互相认出对方的类型和函数签名 —— 这件事 Go 从设计上就没打算让你轻松做到。
