MakeFunc生成的函数必须严格匹配目标签名，否则panic；需用reflect.TypeOf((*T)(nil)).Elem()获取原始类型，in/out切片须与参数/返回值数量类型完全对齐，闭包中调用原函数要注意reflect.Call性能开销和panic传播问题。
MakeFunc 生成的函数必须匹配目标签名，否则 panic
Go 的 reflect.MakeFunc 不做运行时类型推导，它只检查你传入的 funcType 和闭包返回值是否严格对齐。常见错误是参数数量或类型错位，比如把 *int 当成 int，或漏掉 error 返回——哪怕逻辑上不返回 error，签名里写了就必须 return nil。
- 先用
reflect.TypeOf((*YourFunc)(nil)).Elem()拿到原始函数类型，别手写reflect.FuncOf(...)，容易漏掉导出性或指针修饰 - 闭包里接收的
in []reflect.Value是按签名顺序排列的，in[0]就是第一个参数，别靠猜 - 返回值切片
out长度必须等于函数签名的返回个数；如果签名是func() (int, error)，你就得 return[]reflect.Value{reflect.ValueOf(42), reflect.ValueOf(nil)}
适配器里嵌套调用原函数时，注意 reflect.Call 的开销和 panic 传播
很多通用适配器（比如日志、重试、权限校验）会在 MakeFunc 闭包里用 originalFunc.Call(in) 调用真实函数。这看似简单，但有两处硬伤：一是 reflect.Call 比直接调用慢 10–50 倍，二是原函数里的 panic 不会自动转成 error，而是直接向上冒泡，绕过 defer。
- 高频路径慎用 —— 如果适配器要跑在每秒万级请求的 handler 里，建议用代码生成（
go:generate+text/template）替代MakeFunc - 想捕获原函数 panic？得在闭包里显式
defer func() { ... if r := recover(); r != nil { ... } }()，然后手动构造 error 返回值 -
originalFunc必须是reflect.Value类型且 Kind == Func，不能是未初始化的 nil 或方法值（method value）——后者得用reflect.ValueOf(&obj).MethodByName("Name")获取
跨包函数适配时，确保所有类型在反射上下文中可寻址
当你试图用 MakeFunc 包裹一个定义在其他包里的函数（比如 http.HandlerFunc），常遇到 panic: reflect: Call using zero Value 或类型不匹配。根本原因是：非导出字段、未导出类型、或 interface{} 里装了不可反射的底层值（如 unsafe.Pointer）。
- 检查目标函数参数/返回值中是否含非导出 struct 字段 —— 反射无法读写它们，
MakeFunc闭包里取值会失败 - 避免用
interface{}作为中间载体传递函数；直接传reflect.ValueOf(yourFunc)，并确保yourFunc是变量而非字面量表达式 - 如果被适配的是方法（如
(*MyServer).ServeHTTP），注意它是 method value，不是 func；要用reflect.ValueOf(&s).MethodByName("ServeHTTP")，而不是reflect.ValueOf(s.ServeHTTP)
调试 MakeFunc 闭包时，打印类型比猜更可靠
最耗时间的不是写逻辑，而是搞不清 in 里每个 reflect.Value 到底是什么类型、有没有地址、能不能 Interface()。别靠文档记忆，现场打出来看。
立即学习“go语言免费学习笔记（深入）”；
- 加一句
fmt.Printf("in[%d]: %v, kind=%v, canAddr=%t\n", i, v.Type(), v.Kind(), v.CanAddr())能立刻暴露字段不可寻址、指针未解引用等问题 - 对返回值，用
reflect.ValueOf(err).Kind() == reflect.Ptr && !reflect.ValueOf(err).IsNil()判断 error 是否有效，别直接v.Interface().(error)强转 - 测试时用
go test -gcflags="-l" -run=TestMakeFunc关闭内联，避免编译器优化掉你打的日志
MakeFunc，而是让它的行为在边界条件下（空指针、panic、并发调用、跨包类型）依然可预测。 
