Go plugin包是动态加载插件唯一合法入口，reflect仅支持加载后类型安全调用；正确做法是plugin.Symbol获取后立即类型断言，避免reflect.Value.Call导致50–100倍性能损耗。
Go 的 plugin 包才是动态加载插件的唯一合法入口，reflect 本身不支持加载外部代码——它只负责在插件加载后做类型安全调用。性能瓶颈不在“反射是否能加载”，而在于“加载后怎么调用才不拖垮吞吐”。
plugin.Open 后立即用 reflect.Value.Call 调用方法必慢
这是最常见也最容易被忽略的误用：插件符号拿到后不做类型断言，直接 reflect.ValueOf(sym).MethodByName("Do").Call()。
- 每次调用都触发完整的反射开销：receiver 可寻址性校验、参数类型逐个转换、栈帧重建，单次
Call稳定在 80–120 ns，比直接调用慢 50–100 倍 - 哪怕你缓存了
reflect.Method，只要没绕过Call，就省不掉这 90% 的开销 - 更糟的是，如果插件导出的是函数（非方法），
MethodByName返回零值，Call直接 panic “call of reflect.Value.Call on zero Value”
正确姿势：先类型断言，再直接调用
插件必须导出满足明确定义接口的变量（如 var Plugin impl.PluginInterface），主程序通过 plugin.Symbol 获取后立刻断言：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
sym, err := plug.Lookup("Plugin")→ 拿到interface{} -
if p, ok := sym.(impl.PluginInterface); ok { p.Do() }→ 编译期生成跳转表，零反射开销 - 绝不把
sym丢给reflect.ValueOf再查方法——那是把编译期已知信息硬拖进运行时查表
热路径上彻底绕过 reflect.Call：用 MakeFunc 预生成闭包
当插件方法签名固定（比如所有插件 handler 都是 func(context.Context) error），可在初始化阶段用 reflect.MakeFunc 构建纯函数：
立即学习“go语言免费学习笔记（深入）”；
- 获取方法类型：
typ := reflect.TypeOf((*MyPlugin)(nil)).Method(0).Type - 生成闭包：
fn := reflect.MakeFunc(typ, func(args []reflect.Value) []reflect.Value { ... }) - 后续直接
fn.Call()→ 实际走的是普通函数调用，无反射开销 - 注意：该方式要求签名绝对一致，且不能用于方法名动态变化的场景
最容易被忽略的点：插件 ABI 兼容性失败不是性能问题，而是根本跑不起来
一旦 plugin.Open 失败，错误信息如 undefined symbol: main.(*Config).Validate，说明插件引用了主程序未导出类型或内部包——这不是反射能解决的，而是构建阶段就必须约束的 ABI 边界问题。缓存、优化、闭包都建立在 Open 成功的前提下；否则所有反射调用连执行机会都没有。
