Go 的 reflect 包仅桥接类型，不加载插件；plugin.Open 加载后须用 reflect.ValueOf(sym).Interface() 实现类型归一化，再断言；调用前需校验函数签名；热卸载不可行；ABI 兼容性（Go 版本、平台、编译标志）必须严格一致。
Go 的 reflect 包不负责加载插件，只负责桥接类型 —— 你不能用 reflect.ValueOf 加载 .so 文件，必须用 plugin.Open；但没 reflect，你就没法安全地把插件里导出的 interface{} 转成你想要的函数或结构体。
plugin.Open 后必须用 reflect 做类型中转
插件通过 plugin.Open("xxx.so") 加载后，所有符号（比如 PluginInstance）都以 interface{} 形式返回。这个值在主程序和插件中即使类型定义完全一样（同名、同字段），Go 也会视为不同类型 —— 因为包路径不同。直接写 p := sym.(MyPlugin) 必然 panic。
正确做法是先用 reflect.ValueOf(sym).Interface() 触发类型“归一化”，再做断言：
sym, _ := plug.Lookup("PluginInstance")-
v := reflect.ValueOf(sym)→ 得到一个reflect.Value -
obj := v.Interface()→ 这一步关键：它让 runtime 把底层类型“映射”到主程序已知的接口视图 if p, ok := obj.(Plugin); ok { p.Init() }
反射调用前必须校验函数签名，否则 panic 不报具体原因
如果你用 reflect.ValueOf(fn).Call() 调用插件导出的函数，但参数数量或类型不匹配，错误信息只会是 reflect: Call with too few or too many input arguments 或更模糊的 call of reflect.Value.Call on zero Value —— 完全看不出是哪个参数错了。
立即学习“go语言免费学习笔记（深入）”；
实操建议在注册/加载阶段就做静态检查：
- 约定统一签名，例如
func(context.Context, map[string]interface{}) error - 用
reflect.TypeOf(fn).NumIn()检查入参个数是否为 2 - 用
.In(0).Kind() == reflect.Interface确认第一个参数是context.Context（注意：不能用== reflect.TypeOf((*context.Context)(nil)).Elem()，得用Implements判断接口） - 传参时别直接
reflect.ValueOf(42)，目标函数若要int64，得先int64(42)再reflect.ValueOf()
插件热加载 ≠ 热卸载，reflect 无法绕过这个限制
plugin.Close() 只关闭句柄，不会清理已注册的函数指针、全局变量或 goroutine。再次 plugin.Open() 同一路径会失败，报 plugin: symbol not found 或引发竞态 —— 这不是反射的问题，而是 ELF 共享库机制本身限制。
这意味着：
- 别指望靠
reflect实现“卸载后重载”；进程重启才是唯一干净方案 - 如果真要热替换，得靠外部进程管理（如主程序 fork 子进程跑插件，用 RPC 通信）
-
reflect.Value.Call()调用的函数一旦执行，其栈帧、闭包捕获的变量都会留在内存，plugin.Close()不影响它们
真正容易被忽略的是：反射桥接依赖 ABI 兼容性 —— 插件和主程序必须用完全相同的 Go 版本、GOOS/GOARCH、编译标志（比如都开了 -gcflags="-l"）构建，否则 plugin.Open 成功，但 Lookup 返回的 interface{} 在 reflect.ValueOf 后可能类型错乱，panic 信息毫无提示性。
