Golang反射中MakeFunc的性能怪圈与正确运用-Golang-PHP中文网

reflect.makefunc本身不慢，慢的是在热路径（如http handler）中反复调用它；其生成的函数是纯go函数，调用开销≈直接调用，但每次makefunc需解析类型、校验签名、分配闭包，耗时200–400 ns。

golang反射中makefunc的性能怪圈与正确运用

reflect.MakeFunc 本身不慢，慢的是你每次都在热路径上重复调用它——它只该在初始化阶段执行一次。

很多人误以为 reflect.MakeFunc 生成的函数“带反射开销”，其实不是：它返回的是纯 Go 函数值，后续调用完全绕过反射系统。真正拖慢性能的，是把 MakeFunc 放在请求处理循环里反复执行（比如 HTTP handler 中每次请求都 MakeFunc 一次）。

每次 MakeFunc 都要解析 typ、校验签名、分配闭包结构体，开销约 200–400 ns（压测数据）
生成后的函数调用耗时 ≈ 直接调用，fn(1, "a") 和 reflectedFn(1, "a") 差距可忽略
错误模式：http.HandleFunc("/x", func(w http.ResponseWriter, r *http.Request) { handler := reflect.MakeFunc(...); handler.Call(...) }) —— 这里 MakeFunc 被执行了成千上万次

它对函数类型极其敏感，稍有不符就 panic，不是“尽力而为”的适配器。

Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。

下载

拒绝命名返回值：func(int) (v int) 会 panic；必须写成 func(int) int
方法值不能直传：reflect.ValueOf(s.Foo).Type() 拿到的是 func(*S, int) string，但你传给 MakeFunc 的目标类型若漏掉 *S 参数，运行时 panic
接口方法不可达：io.Reader.Read 是接口方法，不能直接取 reflect.Value 后喂给 MakeFunc；得先绑定实例：func(p []byte) (n int, err error) { return r.Read(p) }
校验建议：在初始化时用 typ.NumIn() / typ.NumOut() 显式断言，别等 runtime panic

MakeFunc 的回调函数（func([]reflect.Value) []reflect.Value）不是代理，是值搬运工——每个细节错一点，就 panic 或返回垃圾值。

in[i].Interface() 前必须检查 in[i].CanInterface()，否则 “call of Interface on zero Value”
返回 nil error 不能写 reflect.ValueOf(nil)（类型不匹配），得用 reflect.Zero(typ.Out(1))
可变参数函数（func(...int)）在 in 中仍是逐个 reflect.Value，不是单个切片；需手动收集再转 []int
不要假设参数顺序或数量：len(in) 必须等于 typ.NumIn()，否则 panic