reflect.makefunc 无法直接满足接口，因其返回 reflect.value 类型而非原生函数；必须通过 .interface() 转为具体函数类型（如 func(int) string），再手动赋值给接口变量或包装进预定义结构体（如 funchandler）实现接口。
为什么直接用 reflect.MakeFunc 无法满足接口
因为 reflect.MakeFunc 返回的是 reflect.Value 类型的函数值，它本身不是 Go 的原生函数类型，更不会自动实现接口。如果你把 reflect.MakeFunc 的结果直接赋给接口变量，会 panic：「cannot use … (type reflect.Value) as type … in assignment」。接口的底层需要真实函数地址，而 reflect.Value 是运行时描述，不是可调用实体。
必须先用 reflect.MakeFunc 构造函数，再用 reflect.Value.Call 调用
真正能“动态生成并满足接口”的路径只有一条：先用 reflect.MakeFunc 创建一个闭包式函数值，再通过 reflect.Value.Call 触发执行——但注意，这仍然不等于“让该函数实现某个接口”。要让它被当作接口实例使用，你还得把它转成具体函数类型（如 func(int) string），然后手动赋值给接口变量。
-
reflect.MakeFunc的第一个参数是目标函数类型的reflect.Type，比如reflect.TypeOf((*io.Reader)(nil)).Elem()不行，必须是具体函数签名，如reflect.TypeOf(func() {}).Type() - 第二个参数是
func([]reflect.Value) []reflect.Value，即你提供的调度逻辑；返回值必须严格匹配目标函数的返回类型个数和类型 - 生成后必须用
.Interface()转成原生函数，例如：fn := reflect.MakeFunc(sig, impl).Interface().(func(int) string) - 如果目标接口是
type Handler interface { Serve(int) string }，你不能让reflect.MakeFunc直接产出Handler，而要先生成func(int) string，再包装成实现Handler的 struct 或用接口转换
常见错误：试图用 reflect.New 创建接口实现体
reflect.New 只能创建指针，且类型必须是具体类型（如 *MyStruct），不能是接口类型。写 reflect.New(reflect.TypeOf((*MyInterface)(nil)).Elem()) 看似合理，但 reflect.TypeOf((*MyInterface)(nil)).Elem() 是接口类型，reflect.New 会 panic：「reflect: New of non-zero type」。Go 的接口本身不可实例化，必须靠具体类型实现。
- 正确做法是：定义一个空 struct，用反射给它的方法字段赋值（不推荐）或直接硬编码实现——反射无法“动态绑定方法到类型”
- 想动态满足接口，本质是动态构造满足该接口所有方法签名的类型，而 Go 在运行时不允许新增方法；所以实际可行方案只有：预定义一个通用 wrapper struct，用字段存函数，方法里转发调用
- 例如：
type FuncHandler struct{ Serve func(int) string }，然后实现func (f FuncHandler) Serve(x int) string { return f.Serve(x) }，再用反射设置Serve字段
性能与边界：别在热路径用 reflect 实现接口适配
每次 reflect.MakeFunc + .Interface() 转换都有明显开销，比直接函数调用慢 10–100 倍；而且一旦涉及接口转换，还要多一层类型断言或接口包装。更隐蔽的问题是：反射生成的函数无法被编译器内联、逃逸分析可能失准、GC 压力略增。
- 仅建议用于配置驱动、插件加载、测试 mock 等低频场景
- 若需高频调用，应提前生成并缓存
reflect.Value或原生函数，避免重复MakeFunc - 注意：
reflect.MakeFunc返回的函数值在 GC 中是可达的，只要还有引用就不会被回收；但若保存在 map 中又未清理，容易内存泄漏
真正难的不是怎么写反射代码，而是判断“是否真的需要反射”——多数时候，用函数选项、策略接口或代码生成（go:generate）更稳更快。
