reflect.MakeFunc不是万能函数包装器，仅支持纯函数类型、拒绝命名返回值、不兼容方法值，签名不符即panic；需用闭包转换命名返回、校验参数/返回值数量与可操作性，并避免高频使用。
reflect.MakeFunc 能动态生成函数，但**不是万能的函数包装器**——它只接受纯函数类型、拒绝命名返回值、不兼容方法值，且一旦签名对不上就 panic。用错比不用更危险。
为什么 reflect.MakeFunc 会 panic: "cannot use function with named results"
Go 反射对函数签名极其严格：reflect.MakeFunc 只认 func(int) int 这类“匿名返回”形式，遇到 func(int) (result int) 或 func() (val int, err error) 直接崩溃。
- 检查方式：用
reflect.TypeOf(fn).Out(i).Name()遍历每个返回值，只要任意一个非空字符串，就不能传给MakeFunc - 修复手段：不能硬改原函数签名，得在外层套一层闭包转成匿名形式，例如
func(x int) int { v, _ := original(x); return v } - 常见陷阱：HTTP handler 类型
http.HandlerFunc是func(http.ResponseWriter, *http.Request)，没问题；但自定义带命名返回的封装函数，必须先解包
如何安全构造 fn func([]reflect.Value) []reflect.Value 闭包
这个回调函数不是“代理”，而是“值搬运工”：输入是参数切片，输出是返回值切片，长度和类型必须与函数签名完全一致。
- 务必先校验：
typ.NumIn() == len(in)和typ.NumOut() == len(out)，否则运行时 panic - 参数提取别想当然：用
in[0].Interface()前先确认in[0].CanInterface()，否则 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 只处理函数类型，不处理方法值（method value）或接口方法。你看到的 s.Method 表面像函数，底层其实是 func(*Service, *Req) (*Resp, error) —— 多了一个接收者参数。
- 错误写法：
reflect.ValueOf(s.Handle).Type()拿到类型后直接喂给MakeFunc，再调用时漏传*Service，panic - 正确做法：先绑定接收者，转成纯函数：
handler := func(req *Req) (*Resp, error) { return s.Handle(req) }，再对handler取Type() - 接口方法（如
io.Reader.Read）无法直接反射调用 —— 接口值本身不含完整类型信息，reflect.ValueOf(r).MethodByName("Read")才是正路，但那和MakeFunc无关
性能与调试：别在 hot path 上用，也别靠猜类型
reflect.MakeFunc 生成的函数调用开销远高于普通函数，且内部逻辑出错时堆栈难读。它适合框架初始化、测试桩、适配器生成等低频场景，不适合高频业务逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 每次调用都经过反射解包/打包，实测比直接调用慢 20–50 倍；若闭包里再嵌套
original.Call(in)，开销叠加 - 调试时别背文档：在闭包开头加
fmt.Printf("in[0]: %v, kind=%v, canInterface=%t\n", in[0], in[0].Kind(), in[0].CanInterface())，比查手册快十倍 - 跨包使用时，确保所有参数/返回类型都是导出的（首字母大写），否则
reflect.Value.Interface()会失败，报 "reflect: Call using zero Value"
reflect.Value 都可操作、以及意识到——很多你以为能动态包装的函数，其实根本不符合 MakeFunc 的苛刻前提。 
