最常见原因是字段为string、int64等指针类型且值为nil，直接调v.Interface()触发panic；必须先判断v.Kind()==reflect.Ptr && v.IsNil()，再决定跳过、填NULL或报错。
反射拼批量 INSERT 时为什么一跑就 panic
最常见原因是字段为 *string、*int64 等指针类型且值为 nil，但代码直接调用 v.Interface() —— 这会触发 reflect: call of reflect.Value.Interface on zero Value。Go 反射不区分“空指针”和“有效指针”，v.IsValid() 对 nil 指针也返回 true，不能靠它防崩。
- 必须先判断：
v.Kind() == reflect.Ptr && v.IsNil()，再决定跳过该字段、生成NULL或报错 - 若字段是嵌套指针（如
**string），需循环v.Elem()直到非指针或IsNil() - 结构体字段含
interface{}时，要额外用v.Elem().Kind()解一层再取值，否则v.Interface()返回的是空接口本身
怎么用反射安全生成 INSERT INTO ... VALUES (?, ?, ?), (?, ?, ?)
核心不是“拼 SQL 字符串”，而是同步构建两样东西：SQL 占位符模板 + 参数切片。字段顺序、是否忽略零值、db tag 映射都得在反射遍历时确定。
- 用
reflect.StructTag.Get("db")读列名， fallback 到字段名（strings.ToLower(v.Type().Name())） - 对每个非忽略字段，追加一个
"?"到占位符列表，并把v.Interface()（已确保非 nil）追加到args切片 - 每批最多 500 行；单行字段多或含大文本时，建议压到 200 行以内，避免撞
max_allowed_packet - 别在循环里反复调
reflect.TypeOf(v)和v.NumField()，这些结果可缓存，否则性能损失明显
sqlx.NamedExec 和原生 db.Exec 对反射生成的 SQL 要求不同
反射生成的语句如果含命名参数（如 :name），喂给 database/sql 的 db.Exec 会静默失败——它只认位置参数 ?，把 :name 当字面量处理，导致数据插错列甚至报错。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
sqlx.NamedExec接收struct或map[string]interface{}，反射阶段就该按命名方式组织参数，不用手动拼占位符 - 用原生驱动时，反射必须输出纯
?占位符 + 严格顺序的[]interface{}，且字段遍历顺序必须与INSERT列顺序一致 - 混用会出问题：比如反射生成了
VALUES (:name, :email)，却传给db.Exec，最终执行的是字面量:name字符串，不是绑定值
GORM CreateInBatches 为什么不能用反射自动包装
因为 CreateInBatches 不接受 interface{} 切片，只认具体类型的值切片（如 []User），且内部依赖 reflect.Type 做字段映射。你用反射把 []interface{} 塞进去，GORM 会 panic：“reflect: call of reflect.Value.Type on zero Value”。
立即学习“go语言免费学习笔记（深入）”；
- 反射生成的通用插入器，和 GORM 是两条路：前者控制 SQL 和参数，后者接管整个 ORM 流程
- 想兼容 GORM，反射层只能用于预处理（如过滤字段、转换时间格式），最后仍要传原始
[]User给CreateInBatches - 若结构体字段含
json:或自定义 tag，GORM 默认不读，得额外注册gorm.Namer，反射层无法绕过这个限制
真正难的不是遍历字段，而是字段类型、空值、tag 映射、驱动差异这四者交叉时的边界判断——少一个 IsNil() 检查，或错一行占位符顺序，生产环境就丢数据或报错。
