Go反射调用慢主因是reflect.Value.Call重复执行编译期可确定的类型校验、参数转换和栈帧重建，实测比直接调用慢50–100倍；最常见panic原因是receiver不可寻址，需传指针而非值。
Go 反射调用慢不是因为“用了反射”，而是每次 reflect.Value.Call 都在重复做编译期本可确定的事——类型校验、参数转换、栈帧重建，这些开销无法被编译器优化，实测比直接调用慢 50–100 倍。
为什么 reflect.Value.Call 一调就 panic
最常见原因是 receiver 不可寻址。比如：
-
reflect.ValueOf(v).MethodByName("Foo").Call()中v是值类型（struct{}或int），reflect.Value就不是 addressable，立刻 panic “call of reflect.Value.Call on zero Value” - 必须传指针：
reflect.ValueOf(&v)，而非reflect.ValueOf(v) - 方法不存在时
method.IsValid()返回false，不检查就Call()会 panic - 参数数组
[]reflect.Value每个元素必须严格匹配签名：int 和 int64 视为不同类型，不手动.Convert()就 panic
缓存 MethodByName 真的能提速吗
不能省掉 Call 开销。缓存 reflect.Value.MethodByName("Foo") 只省掉了字符串查找和方法表遍历（占总开销约 15–20%），Call 本身仍是重头戏。
- 真正该缓存的是
reflect.Method，它只读、全局单例；reflect.Value每次都新建，缓存等于白干 - 推荐 key：用
uintptr(unsafe.Pointer(t))，其中t = reflect.TypeOf(&v).Elem()，零开销且稳定 - 避免用
t.String()或t.PkgPath() + "." + t.Name()：匿名 struct 无效，vendoring 下易冲突 - 缓存结构建议含
in, out []reflect.Type，方便后续参数校验预检
热路径上彻底绕过 Call 的三种方式
高频调用场景下，“少调几次”不如“根本不调”。有三类落地路径：
Colly Golang Web Scraper and Crawler Framework
下载
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
立即学习“go语言免费学习笔记（深入）”；
-
用
reflect.MakeFunc生成闭包：适用于固定签名（如func(ctx context.Context) error），初始化阶段生成纯函数，运行时零反射开销；但不支持动态方法名 -
用
unsafe直接算方法入口地址：Go 1.14+ 后internal/abi.Type布局稳定，可预计算偏移并构造函数指针；必须确保签名和参数绝对匹配，否则 runtime crash -
字段级生成 getter/setter 闭包：对
User.Name预算unsafe.Offsetof(User{}.Name)，封装为func(v interface{}) string；GC 分配趋近于零，但要求字段布局稳定
什么时候该放弃反射，改用代码生成
只要满足以下任一条件，就该切到 go:generate：
- 类型固定且数量可控（如 ORM 模型、API 请求/响应结构体）
- 操作高频（HTTP 解码、DB 查询结果扫描、gRPC 序列化）
- 性能敏感（P99 延迟要求 ≤1ms）
别留“半吊子”方案：既用生成代码又保留反射兜底，维护成本翻倍且性能不稳。最容易被忽略的点是——反射的瓶颈不在 Call 动作本身，而在每次调用前的 receiver 校验和参数转换；哪怕你缓存了 reflect.Method，只要没绕过这两步，热路径仍卡在 runtime 校验上。
