缓存字段索引能解决80%反射拼SQL性能问题：初始化时用reflect.Type.FieldByName查一次存[]int，后续用FieldByIndex；键必须是reflect.Type；需校验nil指针、interface{}解包、db tag约束、参数协议匹配及unsafe.Offsetof慎用。
每次反射遍历结构体都慢，缓存字段索引最直接
反射拼 SQL 最耗时的环节不是取值，而是每次调用 reflect.Value.FieldByName 做字符串匹配——字段越多、嵌套越深，线性扫描越久。你不需要重写整个 ORM，只需把“字段名 → 字段位置”这层映射缓存下来。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
reflect.Type.FieldByName在初始化阶段查一次，存[]int（即Field.Index），后续直接走reflect.Value.FieldByIndex - 缓存键必须是
reflect.Type，不能是结构体指针或 interface{}，否则类型擦除后无法命中 - 字段增删、顺序调整、甚至加了
//go:notinheap都会让缓存失效，所以只对稳定模型（如 DB 实体）启用 - 别缓存
reflect.Value，它带运行时状态，会逃逸到堆上，反而加重 GC
nil 指针 panic 是高频错误，检查必须放在反射取值前
动态拼 WHERE 条件时，*string、*int64 这类字段一旦为 nil，直接调 v.Interface() 就 panic。这不是反射本身的问题，而是没做前置校验。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对每个字段先判断：
v.Kind() == reflect.Ptr && v.IsNil()，为 true 则跳过或生成IS NULL - 别依赖
v.IsValid()—— 它对 nil 指针返回 true，但后续v.Interface()仍崩 - 如果字段是
interface{}类型，需额外v.Elem()解一层再判断，否则拿到的是空接口而非底层值 - 用结构体 +
dbtag（如`db:"user_name"`）比 map 更安全，类型和语义都在编译期约束
sqlx.Named 和原生 database/sql 的参数格式不兼容
反射生成的 SQL 字符串里写了 :name，却喂给 db.Query，就会出现 sql: expected 0 arguments, got 1。这不是 bug，是参数协议错配。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 反射阶段就要决定目标驱动：选
sqlx就保持传 struct/map；选原生驱动，就得拆成两个切片 ——args存值，placeholders存?，最后拼成WHERE name = ? AND age > ? -
sqlx.In对IN (?)友好，但要求 slice 类型明确，反射中需用v.Kind() == reflect.Slice判断，并用v.Len()动态生成对应数量的? - 别在 SQL 字符串里硬拼命名参数再交给原生驱动 —— 占位符不会被识别，变成字面量，查不到数据且无报错
缓存不是万能的，unsafe.Offsetof 才是热路径终极解法
连 FieldByIndex 都嫌重？那说明你已经卡在毫秒级优化上了。这时候可以下沉到内存偏移层面，彻底绕过反射 API。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
unsafe.Offsetof(User{}.Name)算出字段地址偏移，封装成闭包：func(u *User) string { return *(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(u)) + offset)) } - 闭包必须接收指针，且确保结构体类型不会被 GC 移动（命名类型安全，但接口类型要警惕）
- 字段重排、加字段、启用
//go:build !no_unsafe都会让 offset 失效 —— 这不是 bug，是你和编译器的契约被打破了 - 这种优化只适合明确性能瓶颈点，比如高频日志过滤、实时风控规则匹配，别用在通用 DAO 层
