Go的reflect包不能动态加载插件，plugin包才是唯一合法入口；plugin.Open是加载插件的唯一方式，反射仅用于加载后的类型安全调用，且需通过公共接口断言，插件必须用-buildmode=plugin编译、与主程序ABI完全兼容。
Go 的 reflect 包本身不能动态加载插件，plugin 包才是唯一合法入口；反射只负责加载后的类型安全调用，不是加载器。
plugin.Open 是加载插件的唯一入口
所有所谓“用反射加载插件”的说法都是误传。Go 没有字节码加载器，reflect.ValueOf 无法从磁盘读取并执行未编译进主程序的代码。真正能打开外部模块的只有 plugin.Open("xxx.so") —— 它基于 ELF/Dylib 机制，与操作系统共享库加载器协同工作。
常见错误现象：plugin.Open: failed to load plugin: plugin was built with a different version of package xxx，说明插件和主程序 Go 版本、GOOS/GOARCH 或构建标签不一致。
- 插件必须用
go build -buildmode=plugin编译，不能用默认模式 - 主程序不能 import 插件包路径，否则会静态链接，失去动态性
- Windows 平台无官方支持，
plugin包仅限 Linux/macOS
plugin.Lookup 返回 interface{}，必须用 reflect 做类型桥接
plugin.Symbol 返回的是 interface{}，不是可直接调用的函数或结构体。直接类型断言（如 sym.(MyPlugin)）会失败，因为插件中定义的 MyPlugin 和主程序中同名类型在 Go 类型系统里不等价（包路径不同）。
立即学习“go语言免费学习笔记（深入）”；
正确做法是先用 reflect.ValueOf(sym).Interface() 转成接口值，再断言到预定义公共接口：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
sym, err := plug.Lookup("PluginInstance")
if err != nil {
panic(err)
}
v := reflect.ValueOf(sym).Interface()
if p, ok := v.(Plugin); ok {
p.Init()
}
- 插件导出的变量（如
var PluginInstance Plugin）必须是满足公共接口的导出变量 - 公共接口需定义在独立模块（如
github.com/yourorg/pluginiface），主程序和插件都 import 它 - 跳过
reflect.ValueOf(sym).Interface()直接断言，大概率触发interface conversion: interface {} is not xxx
反射调用前必须校验函数可导出且签名匹配
Go 反射无法访问未导出函数（小写开头），reflect.Value.Call 调用私有方法会 panic：call of reflect.Value.Call on unexported method。这不是权限问题，而是编译器根本没生成该符号的反射信息。
动态调用还极易因参数类型或数量不匹配崩溃，错误如：reflect: Call with too few or too many input arguments。
- 插件函数必须首字母大写，例如
func Handle(ctx context.Context, data map[string]interface{}) error - 调用前应检查：
fn.Kind() == reflect.Func且fn.Type().NumIn() == 2 - 传参时避免原始值直传：若目标期望
int64，就别传reflect.ValueOf(42)（它是int），先转成int64再包装 - 高频调用场景建议缓存
reflect.Value，避免重复reflect.ValueOf(fn)开销
插件无法卸载，热插拔本质是替换式加载
*plugin.Plugin 不支持卸载。调用 plug.Close() 仅释放句柄，已注册的函数指针、全局变量、goroutine 仍驻留内存。再次 plugin.Open() 同一路径可能报错 plugin: symbol not found 或引发竞态。
所谓“热插拔”，实际是进程级生命周期管理：新插件加载成功 → 通知旧插件 graceful shutdown → 切换调用引用 → 旧插件资源靠 GC 逐步回收。
- 不要依赖
Close()实现功能切换，它不清理运行时状态 - 插件中启动的 goroutine 必须响应
context.Context取消信号，否则会泄漏 - 跨平台兼容性差是硬伤；多数生产场景更适合“接口 + 配置驱动”的软插件方案
最易被忽略的一点：插件中若引用了主程序的未导出类型（比如 main.(*Config).Validate），plugin.Open 会直接失败，错误指向 undefined symbol —— 这类依赖必须全部解耦到公共接口模块中。
