go plugin仅linux稳定可用，需主程序与插件完全一致的go版本、goos/goarch、禁用cgo，且类型不共享，必须通过接口或序列化通信。
Go 的 plugin 包不是通用动态库加载器，它只在 Linux 上稳定可用，且主程序与插件必须用完全相同的 Go 版本、GOOS/GOARCH、禁用 CGO（CGO_ENABLED=0），否则 plugin.Open 几乎必然失败。
plugin.Open 找不到 .so 或报 “built with different version”
这不是路径写错那么简单。根本原因是 Go 插件依赖编译时嵌入的完整类型元数据，只要主程序和插件之间有任意一项不一致——比如 Go 小版本号差一个 patch（1.22.2 vs 1.22.3）、一方用了 -tags netgo 而另一方没用、或插件里 import 了主程序的私有模块路径（如 myapp/internal/util）——都会触发 ABI 不兼容错误。
实操建议：
- 统一用绝对路径加载：
plugin.Open("/home/user/myapp/plugins/math.so")，别传相对路径 - 构建插件时强制禁用 CGO：
CGO_ENABLED=0 go build -buildmode=plugin -o math.so math.go - 主程序也必须
CGO_ENABLED=0构建，且和插件用同一份go.mod和完全相同的 Go 二进制（推荐用go version逐字比对） - macOS 用户请直接放弃：SIP + dlopen 限制 + 符号签名问题，即使加
-ldflags="-s -w"也大概率失败；Windows 官方不支持，别试
Lookup 到 symbol 却无法断言成函数或接口
常见错误是以为“签名看起来一样就行”。实际 Go 对函数签名做字节级校验：参数名、包路径、是否指针、interface{} 的底层具体类型，全部要严丝合缝。比如插件里定义 func Add(a, b int) int，主程序却用 func(int, int) int 去断言，panic 是确定的。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
实操建议：
- 不要导出裸函数，改用统一接口实例：插件中定义
func Init() Plugin，主程序只依赖type Plugin interface { Do() error } - 该接口必须放在**独立共享模块**（如
github.com/yourorg/pluginapi），主程序和插件都go mod require它，不能复制粘贴定义 - 调试时用
nm -gU math.so | grep Init（macOS）或objdump -t math.so | grep Init（Linux）确认符号真实存在且可导出 - 避免传递含未导出字段的 struct；跨边界优先走
json.RawMessage或显式定义的 DTO
插件 reload 后 init() 重复执行、全局变量残留
plugin.Close() 只释放极少量资源，插件里的 init() 每次 Open 都会重跑，全局变量（DB 连接池、loggers、HTTP handler 注册）全都不受控残留。所谓“热更新”，在原生 plugin 里根本不存在。
实操建议：
- 插件内禁止在
init()中做不可重入操作：不要打开文件、不要调http.HandleFunc、不要启动 goroutine - 所有资源生命周期应绑定到插件实例上，由主程序控制
Plugin.Start()/Plugin.Stop()显式管理 - 真要热更新？换方案：用子进程（
exec.Command）+ gRPC/HTTP 通信，或改用 WASM（TinyGo + wasmtime） - CI/CD 中务必加
// +build linux构建约束，防止 macOS 流水线直接编译失败
最常被忽略的一点：插件和主程序之间没有类型共享。哪怕两个包里写了完全一样的 type Config struct { Port int }，main.Config 和 plugin.Config 在运行时是不同类型，强制转换必 panic。跨边界通信只能靠接口约定或序列化，没有例外。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
