reflect.MakeFunc要求funcType必须是reflect.Func类型且签名严格匹配，回调须返回[]reflect.Value切片，性能差8–12倍，仅适用于低频场景，跨包时需确保所有类型字段导出。
Go 里用 reflect.MakeFunc 创建函数必须满足签名匹配
你不能随便传个类型进去就生成函数——reflect.MakeFunc 要求你提供的 funcType 必须是 reflect.Func 类型，且它的参数和返回值类型必须和你要“代理”或“包装”的目标逻辑严格对齐。
常见错误是直接拿一个普通函数变量（比如 func(int) string）去调 reflect.TypeOf(fn).In(0) 后乱拼，结果传给 MakeFunc 的是 *reflect.rtype 或不完整签名，直接 panic：reflect: call of reflect.MakeFunc on non-function type。
- 正确做法：用
reflect.TypeOf((*int)(nil)).Elem()这类方式构造类型，或更稳妥地——先定义好目标函数签名的变量，再用reflect.TypeOf提取 - 如果目标是动态适配多种签名，建议用代码生成（
go:generate）或提前注册闭包模板，而不是 runtime 拼reflect.Type -
MakeFunc返回的是reflect.Value，必须用.Call()或显式转成具体函数类型才能调用，不能直接当函数用
为什么不能在 MakeFunc 的回调里直接 return 原始值
回调函数签名固定为 func([]reflect.Value) []reflect.Value，它要求你返回一个 []reflect.Value 切片，每个元素对应函数的一个返回值。哪怕原函数只返回一个 int，你也得手动包装成 []reflect.Value{reflect.ValueOf(42)}。
典型翻车点：忘了把原始返回值转成 reflect.Value，或者切片长度和函数声明的返回值数量不一致，导致 panic：reflect: Call using functionX with wrong number of args。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 返回值切片长度必须等于函数类型声明的返回值个数（
funcType.NumOut()） - 每个元素必须是
reflect.Value，且类型与funcType.Out(i)匹配；类型不匹配会 panic，不是静默转换 - 如果函数有多个返回值（比如
(int, error)），你得自己拆解、判断、构造两个reflect.Value元素
reflect.MakeFunc 和闭包比，性能差在哪
每次调用通过 MakeFunc 生成的函数，底层都要做一次反射调用链路：参数 unpack → 回调执行 → 返回值 pack → 类型检查。相比直接写闭包，多了至少 3–5 层间接跳转和类型系统介入。
实测在热点路径上，MakeFunc 生成的函数调用开销通常是等效闭包的 8–12 倍（Go 1.21，AMD 5800X）。这不是“慢一点”，而是“不该出现在循环里”。
- 仅适合低频场景：如插件注册、测试桩（stub）、配置驱动的简单路由分发
- 别试图用它替代
switch或map[interface{}]func()做高频分发 - 如果真需要动态行为，优先考虑用接口+工厂模式，而非反射函数
跨包使用 MakeFunc 时容易漏掉的导出问题
如果你要包装的函数来自其他包，而它的参数或返回值类型是非导出字段（首字母小写），reflect.MakeFunc 仍能生成函数，但一旦你尝试调用它，就会 panic：reflect: Call of unexported method 或 reflect: value of unexported field。
这不是 MakeFunc 的锅，而是 Go 反射系统对非导出标识符的访问限制：你可以在反射中“看到”它们，但不能“操作”它们（除非是同包）。
- 检查所有涉及的结构体字段、方法、接口实现是否导出
- 尤其注意嵌套结构体里的匿名字段——如果匿名字段类型未导出，整个字段不可反射赋值
- 调试时用
fmt.Printf("%#v", v)看reflect.Value是否为invalid或unexported
MakeFunc 的地方不多，多数时候是设计没想清楚，或者过早优化。 
