Go反射性能差因将编译期确定的事推至运行时，reflect.Value.Call和FieldByName开销大，需用缓存、预计算或代码生成优化；固定类型场景应优先用go:generate替代。
Go反射导致的性能下降无法靠“写得更熟练”来修复，它本质是把编译期能确定的事全推到运行时做；热路径上用一次 reflect.Value.Call 或 FieldByName 就可能拖慢 10–100 倍，必须用缓存、预计算或生成代码绕开。
为什么 reflect.Value.Call 慢得离谱
每次调用都要重复校验 receiver 是否可寻址、逐个转换参数类型、分配临时 []reflect.Value 切片、拆包接口、跳转函数指针、再打包返回值——这些在编译期已知的信息，运行时却要重做一遍。
- 空函数直调约 2 ns，
reflect.Value.Call实测在 20–500 ns 区间，取决于参数数量和 receiver 类型 - 传值类型（如
struct{}）而非指针会直接 panic：call of reflect.Value.Call on zero Value - 缓存
reflect.Method有效，但缓存reflect.Value.Method(i).Call()是白忙——后者绑定具体实例，无法复用 - 真正省事的做法：启动时用
unsafe.Offsetof+ 方法表偏移算出函数地址，封装为闭包，后续调用零反射开销（需确保签名绝对匹配）
FieldByName 是结构体反射的性能黑洞
内部是线性遍历字段列表 + 字符串比对，一个 20 字段的 struct 平均要比 10 次才能命中；字段越多，开销越非线性增长。
Colly Golang Web Scraper and Crawler Framework
下载
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
- 优先用
v.Field(i)，配合注释说明索引含义，比如// Name at index 0 - 字段名稳定时，启动时预计算
map[string]int，存进sync.Map或普通map[uintptr]map[string]int（key 用uintptr(unsafe.Pointer(t))更轻量） - 别缓存
reflect.Value实例本身——它绑定了具体值，不可复用；只缓存reflect.Type和字段偏移数组[]int - 避免在 HTTP handler 或数据库批量循环里反复调用
FieldByName，首请求抖动都可能被放大成 P99 延迟尖刺
什么时候该放弃反射，改用 go:generate
只要类型集合固定、操作高频、性能敏感，就该切走。运行时反射和构建期生成的性能差距是数量级的。
立即学习“go语言免费学习笔记（深入）”；
- 典型适用场景：ORM 模型、API 请求/响应结构体、JSON 序列化、gRPC 编解码
- 生成函数签名必须与标准库一致，比如接收
*T、返回error，才能无缝替换 - CI 中必须校验
go generate后无 diff，否则失败——否则容易漏生成，上线后 fallback 到反射兜底，性能崩盘 - 慎用手写
unsafe.Offsetofgetter/setter：快，但字段增删或 build tag 变动会导致 silent crash，调试成本极高
最难绕开的是那些真未知类型的场景：deep copy 任意 struct、调试时 dump interface{}、插件系统加载未知类型。这些地方反射是刚性需求，只能接受代价，并严格限制调用频次和输入规模——比如只在 debug 模式启用，或加采样率控制。
