reflect.makefunc仅支持纯函数类型，不支持带接收者的方法；需先获取方法的reflect.value再用闭包包装，注意参数/返回值严格对齐、避免运行时panic及性能陷阱。
MakeFunc 不能直接包装方法，只能包装函数类型
你拿到一个 reflect.Method 或者想“反射调用某个结构体的方法”，reflect.MakeFunc 会直接报错或 panic —— 它只接受 func(...interface{}) 这类函数签名的 reflect.Type，不支持接收者（receiver）。常见错误是把 reflect.Value.Method(i) 的结果直接传给 MakeFunc，结果得到 panic: reflect: call of reflect.Value.Call on zero Value。
正确做法是先用 reflect.Value.Method(i) 拿到可调用的 reflect.Value，再用 reflect.MakeFunc 包一层适配器函数（比如统一转成 func([]interface{}) []interface{}），而不是试图让 MakeFunc “生成方法”。
- 要包装方法，必须显式构造闭包：捕获目标
reflect.Value（含 receiver），在闭包里调用.Call() -
MakeFunc的第一个参数必须是纯函数类型，例如reflect.TypeOf(func(int, string) bool { return true })，不能是*T或T的方法签名 - 如果目标函数带指针参数（如
*http.Request），传入的reflect.Value必须是地址，否则Call()会 panic
参数和返回值必须严格对齐，否则 runtime panic
reflect.MakeFunc 生成的函数，在调用时如果实际传入参数个数、类型，或期望返回值个数与原始 reflect.Type 不一致，会在运行时直接 panic，没有编译期检查。最常踩的坑是：把 func(int) (string, error) 类型传进去，却在回调函数里只返回一个 []reflect.Value（少了一个），或者传了三个 int 进去但类型只声明了两个参数。
建议在构造前用 fnType.NumIn() 和 fnType.NumOut() 做校验，尤其当类型来自配置或外部输入时。
- 所有输入参数都必须是
reflect.Value，且.Kind()要匹配（比如int不能传int64） - 返回值切片长度必须等于
fnType.NumOut()，每个元素的.Kind()和类型也要完全一致 - 如果原函数返回
error，你返回的reflect.Value必须是接口类型且底层是error实例，不能是nil（除非该位置允许 nil）
闭包捕获的 reflect.Value 不能是临时对象
很多人写类似 reflect.MakeFunc(fnType, func(in []reflect.Value) []reflect.Value { ... })，然后在闭包里反复调用 someStruct.Field(i) 或 reflect.ValueOf(&x).MethodByName("Foo") —— 这会导致每次调用都重新反射，性能极差；更危险的是，如果闭包里用了局部变量的地址（比如 &localVar），而该变量在函数返回后已出作用域，后续调用可能读到垃圾内存。
真正安全的做法是：在 MakeFunc 外部一次性准备好所有需要的 reflect.Value（比如目标方法、目标实例、固定参数），然后闭包只做转发。
- 不要在闭包里调用
reflect.Value.Field()、.Method()、.Call()等开销大的操作，提前算好 - 如果目标是某个 struct 实例的方法，用
reflect.ValueOf(&s).MethodByName("Bar")得到reflect.Value后，把它作为变量捕获进闭包，而不是每次都重新取 - 避免捕获未导出字段的
reflect.Value，Go 1.19+ 对未导出字段的反射访问有额外限制，可能 panic
Go 1.21+ 中的 unsafe.Pointer 替代方案更轻量
如果你只是想“绕过类型检查，动态拼接函数调用”，reflect.MakeFunc 其实不是最优解 —— 它本质是反射层的函数对象模拟，每次调用都有至少 2~3 层反射 dispatch 开销。在 Go 1.21+，更推荐用 unsafe.Pointer + funcptr 配合 go:linkname 或 runtime.FuncForPC 手动构造调用跳转（仅限极少数高性能场景，如 ORM 方法路由、RPC stub 生成）。
不过这属于非安全边界操作，调试困难、兼容性差。绝大多数业务场景下，老老实实用 MakeFunc 加一层缓存（比如按 reflect.Type 做 map 缓存生成的函数）已经足够。
- 用
sync.Map缓存reflect.Type → func映射，避免重复MakeFunc调用（它本身不 cheap） - 不要用
MakeFunc替代接口实现；如果能定义type Handler interface { Serve(...); }，就别反射生成函数 - 跨 goroutine 复用同一个
reflect.Value是安全的，但注意它内部可能引用了不可复制的底层数据（如unsafe.Slice）
