根本原因是Go编译器在ELF加载阶段进行ABI校验失败，必须确保主程序与插件使用同一GOROOT、相同Go版本、完全一致的构建参数（含-buildmode=plugin）、依赖模块go.sum哈希及CGO_ENABLED状态。
plugin.Open 报 “built with a different version of package” 怎么办
根本不是路径或权限问题，而是 Go 编译器对插件和主程序做了 ABI 级别校验。只要 GOROOT、Go 版本、构建参数（尤其是 -buildmode=plugin）、依赖哈希三者中任一不一致，就直接失败。
- 主程序和插件必须用同一台机器、同一个
go命令编译；不能一个用系统自带 go，一个用 asdf/gvm 管理的版本 - 插件编译时必须显式加
-buildmode=plugin：例如go build -buildmode=plugin -o parser_json.so parser_json.go - 主程序不能用
go run启动，必须先go build成二进制再运行；go run会触发临时构建，导致模块哈希错配 - 若用了
replace或本地require，主程序和插件的go.mod必须完全一致，否则标准库符号表对不上
插件里导出函数被 Lookup 返回 nil
Go 插件只暴露首字母大写的包级标识符，且仅限变量或函数——方法、闭包、结构体、局部定义一律不可见。
-
func Parse(data []byte) (map[string]interface{}, error)✅ 可被Lookup("Parse")找到 -
var Version = "v1.0"✅ 可被Lookup("Version")找到 -
type JSONParser struct{}+func (p JSONParser) Parse(...)❌Lookup("JSONParser")或Lookup("Parse")都返回 nil - 想传递复杂逻辑？用函数返回接口值，如
func NewParser() FileParser，但FileParser接口必须在主程序中定义，插件实现它
Linux 下 plugin.Open 报 “no such file or directory” 但文件存在
这不是路径写错，而是 ELF 动态链接失败：plugin.Open 实际调用 dlopen()，要求所有依赖符号可解析。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 路径必须是绝对路径；相对路径会导致校验失败，错误信息反而变成版本不匹配
- 确保插件编译时未禁用 cgo：
CGO_ENABLED=0会破坏 plugin 模式，必须保持CGO_ENABLED=1 - 用
ldd plugin.so检查是否缺失系统库（如libc.so.6）；若依赖外部 C 库，需在运行时确保其可用 - 避免在插件中 import 主程序没用到的第三方包，否则可能引入隐式符号依赖
viper 读不到嵌入的插件配置文件怎么办
viper.AddConfigPath() 对 embed.FS 完全无效，它只操作本地文件系统。
立即学习“go语言免费学习笔记（深入）”；
- 不要调
viper.SetConfigFile("config.yaml")，改用viper.ReadConfig(bytes.NewReader(data)) - 必须在
ReadConfig前显式调viper.SetConfigType("yaml")，否则报unknown config type - 示例：先
data, _ := assets.ReadFile("parsers/json/config.yaml")，再viper.SetConfigType("yaml")，最后viper.ReadConfig(bytes.NewReader(data)) - 如果插件需要加载自己的配置（比如解析规则），建议把配置内容硬编码为 const string 或 embed 进插件二进制，避免运行时依赖外部文件路径
plugin.Close() 在多数场景下不可靠，真正要支持多格式解析器动态加载，关键不在“怎么写插件”，而在于“怎么让主程序和插件在构建、符号、生命周期上达成严格契约”。稍有松动，就是 runtime panic 或 silent failure。 
