reflect.MakeFunc不是万能函数包装器，仅支持匿名返回的纯函数类型，拒绝命名返回值和方法值，签名不符即panic；需用闭包转换命名返回、校验参数/返回值数量与可操作性，并避免高频使用。
reflect.MakeFunc 不是“动态生成任意函数”的万能胶，它只做一件事：把一个固定签名的桥接函数，适配成另一个指定签名的函数值。用错签名、忽略命名返回或误传方法值，立刻 panic。
为什么 reflect.MakeFunc 会 panic：“cannot use function with named results”
Go 反射对函数类型极其苛刻：reflect.MakeFunc 只接受形如 func(int) string 这类“匿名返回值”的函数类型；一旦遇到 func(int) (result string) 或 func() (val int, err error)，直接崩溃。
- 检查方式：遍历
typ.Out(i).Name()，只要任意一个返回值名称非空字符串，就不能传给MakeFunc - 修复手段：不能改原函数签名，必须在外层套闭包转换，例如
func(x int) string { s, _ := original(x); return s } - HTTP handler 是安全的——
http.HandlerFunc是func(http.ResponseWriter, *http.Request)，无命名返回；但自定义封装如func(req *Req) (resp *Resp, err error)就必须先解包
如何安全构造 body func([]reflect.Value) []reflect.Value
这个 body 函数不是逻辑代理，而是严格的“值搬运工”：输入参数个数、类型、顺序，输出结果个数、类型、顺序，必须和 typ 完全一致，否则运行时 panic。
- 务必提前校验：
typ.NumIn() == len(args)和typ.NumOut() == len(results) - 提取参数前先调用
args[0].CanInterface()，否则args[0].Interface()会 panic：“reflect: call of reflect.Value.Interface on zero Value” - 返回
nil error时，必须用reflect.Zero(typ.Out(1))；reflect.ValueOf(nil)类型不匹配，reflect.Value{}是非法零值 - 若原逻辑返回
(int, error)，你就得返回两个reflect.Value：一个是reflect.ValueOf(42)，另一个是reflect.Zero(reflect.TypeOf((*error)(nil)).Elem())
为什么不能对方法或接口直接用 reflect.MakeFunc
reflect.MakeFunc 只处理函数类型（func(...)），不处理方法值（receiver.method）或接口方法。表面看 s.Handle 像函数，底层其实是 func(*Service, *Req) (*Resp, error)——多一个接收者参数。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
reflect.ValueOf(s.Handle).Type()拿到类型后直接喂给MakeFunc，调用时漏传*Service，panic - 正确做法：先绑定接收者，转成纯函数：
handler := func(req *Req) (*Resp, error) { return s.Handle(req) }，再对handler取Type() - 注意：
reflect.ValueOf(handler).Call(...)才能真正调用；MakeFunc产出的是新函数值，仍需通过Set赋给变量才能使用
最易被忽略的一点：MakeFunc 创建的函数没有 GC 友好性保障，闭包捕获的变量生命周期可能比预期长；高频调用场景下，性能开销和 panic 风险远高于显式函数定义。它适合元编程、mock 构建或插件适配这类“一次创建、长期复用”的场景，而不是替代常规函数逻辑。
