不能直接用reflect.StructTag解析gorm标签，因gorm映射需fallback字段名、处理嵌套、识别embedded及gorm.Model影响；真实映射必须走schema.Parse流程，复用gorm自身schema构建逻辑最稳妥。
为什么不能直接用 reflect.StructTag 解析 gorm 标签就完事？
因为 gorm 的标签解析逻辑不是纯结构体标记读取——它会 fallback 到字段名、处理嵌套结构、识别 embedded 字段，甚至受 gorm.Model 影响。直接拿 structTag.Get("gorm") 拆解，会漏掉 primaryKey 的隐式推导、忽略 column 重命名后的实际列名、更无法处理 foreignKey:"UserID" 这类间接映射。真实映射必须走 gorm 内部的 schema.Parse 流程，否则生成的 SQL 字段和实际执行不一致。
如何安全获取 struct 字段到数据库列名的映射关系？
最稳妥的方式是复用 gorm 自己的 schema 构建逻辑，而不是手写反射解析。关键步骤如下：
- 用
gorm.Open(gormio.Dialector, &gorm.Config{SkipDefaultTransaction: true})创建一个无连接的*gorm.DB实例（避免初始化 DB 连接） - 调用
db.Migrator().FullDataTypeOf(reflect.TypeOf(T{}))获取完整 schema 信息（注意传指针类型*T） - 遍历
schema.Fields，每个field的DBName就是最终 SQL 中使用的列名，Name是 Go 字段名，IsPrimaryKey、IsForeignKey等字段可判断语义 - 若需支持
embedded结构体，必须确保嵌入字段加了gorm.Embedded标签，否则schema不会展开
reflect.Value.Interface() 在映射时为什么常 panic？
常见于对 nil 指针或未导出字段调用 Interface() —— 反射无法访问非导出字段值，而 Interface() 对 nil 指针直接 panic。正确做法是：
- 始终先检查
value.CanInterface()，不满足则跳过该字段（比如只处理导出字段） - 对指针类型，用
value.Elem()前先value.IsValid() && !value.IsNil() - 不要在循环中对每个字段都调用
Interface()；应先用schema.Fields确定哪些字段要取值，再按需用value.FieldByName(field.Name)+ 类型断言提取 - 如果只是生成 INSERT 字段列表（不取值），根本不需要
Interface()，只靠schema就够了
生成 INSERT SQL 时，字段顺序和 struct 定义顺序不一致怎么办？
gorm 的 schema.Fields 默认按 struct 字段声明顺序排列，但一旦存在 embedded 或 gorm:"-" 字段，顺序就会变化。更可靠的做法是：显式按 schema.Fields 的遍历顺序拼接 SQL，而不是依赖 reflect.TypeOf(T{}).NumField() 循环。例如：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
for _, f := range schema.Fields {
if !f.Ignore && !f.Serializer {
columns = append(columns, f.DBName)
placeholders = append(placeholders, "?")
}
}
这里 f.DBName 已经是清洗后的列名，且顺序与 gorm 实际 INSERT 行为完全一致。手动排序或硬编码字段名极易和 ORM 行为脱节。
复杂点在于嵌套结构体字段的 DBName 可能带前缀（如 user_name），而你可能期望扁平化；这需要提前约定命名策略，或在遍历 schema.Fields 时过滤掉 f.Owner == nil 的顶层字段——容易被忽略的是：嵌入字段的 Owner 指向父结构体，不为空。
