FieldByName越用越慢是因为它采用线性遍历而非哈希查找，每次调用都需逐个比对字段名字符串，字段越多平均比较次数越多（如100字段需约50次），且无法内联、不逃逸优化、触发临时内存分配；在循环中高频使用会叠加O(n)开销，导致性能随数据量和字段数指数级恶化。
FieldByName 在 struct 字段遍历中为什么越用越慢
它不是哈希查找，而是线性遍历所有导出字段，每次调用都从头比对字符串。字段数越多，平均比较次数越多——100 字段结构体，FieldByName("ID") 平均要走 50 次字段名比对；更糟的是，这个过程无法内联、不逃逸优化、每次触发内存分配（比如构建临时 reflect.StructField）。你在循环里每行数据都调一次，等于给数据库扫描加了一层 O(n) 额外开销。
常见错误写法：v := reflect.ValueOf(&u).Elem(); v.FieldByName("Name").SetString("x") —— 如果这句在 rows.Next() 循环里，性能会随字段数和数据量指数级恶化。
- 只在初始化阶段查一次字段索引：
reflect.TypeOf(u).FieldByName("Name")返回struct{ Index int; ... }，记下Index值（如0） - 运行时直接用
v.Field(0).SetString("x")，跳过全部字符串匹配 - 缓存建议存在包级
sync.Once初始化的map[reflect.Type]int中，key 用t而非t.String()（避免匿名 struct 或 vendoring 下失效） - 如果结构体类型可能被 plugin reload，缓存需带类型版本号或 unsafe.Pointer 地址校验，否则字段错位是静默写坏数据
reflect.Value.Call 调用方法时的隐藏开销
ORM 中常需要动态调用 BeforeInsert 或 Validate 方法，但 reflect.Value.MethodByName("Validate").Call([]reflect.Value{}) 比直接调用慢 50–100 倍。这不是“查方法名慢”，而是整个调用链绕过了所有编译器优化：重建栈帧、参数类型校验、反射参数转底层寄存器/栈布局、再跳进 runtime.call 汇编入口。压测显示空方法调用开销稳定在 80–120 ns，而原生调用仅约 1.2 ns。
缓存 MethodByName 结果只能省掉约 15–20% 开销，真正重头戏是 Call 本身。别在热路径里嵌套调用，也别对每个 struct 实例重复 Call。
立即学习“go语言免费学习笔记（深入）”；
- 若方法签名固定（如
func() error），改用reflect.MakeFunc在初始化阶段生成闭包，后续调用就是纯函数调用，零反射开销 - 缓存结构建议为
struct{ method reflect.Value; in, out []reflect.Type }，方便提前校验参数兼容性 - 接收者必须可寻址且导出；
Call前务必检查method.IsValid() && method.Type().NumIn() == len(args)
scanIntoStruct 时 .Elem() 和 CanSet() 的组合陷阱
ORM 的 Scan 逻辑必须传入 *User，但很多人卡在 reflect.ValueOf(dest).Elem().Field(i).Set(...) 这一步 panic。根本原因不是语法错，而是三个条件缺一不可：可寻址（指针）、有效（IsValid()）、可设置（CanSet()）。漏判任何一个，都会在运行时报 reflect: call of reflect.Value.SetString on zero Value 或 cannot set。
- 传参必须是
*T类型，不能是T或interface{}；reflect.ValueOf(interface{})会丢失地址信息 -
.Elem()前必须先.IsValid()，否则 nil 指针调用直接 panic - 每个字段赋值前必须
field.CanSet()，私有字段（小写开头）永远返回 false，不是 bug 是设计 - 别依赖
field.Name做列名匹配——它永远是 Go 导出名（如Name），而 db 标签才是真实列名（如db:"user_name"）
SQL 构建时字段顺序与 map 遍历的隐性错位
INSERT 语句的字段顺序必须和 stmt.Exec() 参数顺序严格一致，而 Go 反射保证 reflect.Type.NumField() 返回顺序 = 源码定义顺序。但很多人用 map[string]int 缓存字段映射，结果 SQL 字段是 (name, age)，参数却是 [age, name]，报错 sql: expected 2 arguments, got 2 却死活看不出哪错了。
这是因为 map 遍历无序，而反射字段顺序有序——二者混用等于主动引入不确定性。
- 字段过滤逻辑（跳过非导出字段、
db:"-"、空标签）必须和 SQL 构建、参数收集两处完全同步 - 不要用 map 存字段索引；要用 slice + index，或预生成
[]int表示有效字段位置 - 嵌套结构体（如
User.Profile *Profile）需递归展开并维护全局字段顺序，否则外键字段会插到中间，破坏 INSERT 语义 - 零值判断不能只看
== ""或== 0；time.Time、sql.NullString等类型需按field.Kind()分类处理
go:generate）反而更稳更快。性能瓶颈从来不在 API 调用本身，而在你没意识到的「顺序假设」「缓存失效」和「类型误判」上。 
