GORM通过struct tag控制字段名需用gorm:"column:xxx"，表名需实现指针接收者的TableName()方法；全局NamingStrategy适用于统一规则场景，关联外键需同时指定foreignKey和column。
如何用 GORM 的 struct tag 控制表名和字段名
默认情况下，GORM 会把 struct 名转成蛇形小写作为表名（如 UserProfile → user_profiles），字段也按同样规则映射。但实际项目里经常要对接已有数据库或遵循特定命名规范，这时必须显式控制。
最直接的方式是用 struct tag：gorm:"column:xxx" 控制字段名，gorm:"primaryKey" 等修饰字段属性；表名则通过实现 TableName() 方法覆盖。
常见错误是只改了字段 tag 却忘了设 column: 前缀，比如写成 gorm:"name" —— 这会被忽略，必须写成 gorm:"column:name" 才生效。
-
gorm:"column:user_name"：强制字段映射到数据库列user_name -
gorm:"primaryKey;column:id"：同时声明主键和列名 -
gorm:"type:varchar(100);not null"：影响建表 SQL，但不影响查询时的字段映射
为什么 TableName() 方法必须是指针接收者
如果定义 func (u User) TableName() string（值接收者），GORM 在反射时可能无法正确识别该方法，尤其在嵌套调用或使用 Scope 时容易静默失效，导致仍走默认表名逻辑。
正确写法必须是：
func (u *User) TableName() string {
return "t_user"
}
这是因为 GORM 内部通过 reflect.ValueOf(model).MethodByName("TableName") 查找方法，而只有指针类型才保证能拿到所有方法。值接收者在某些上下文中（如切片元素取地址前）可能丢失方法集。
gorm.NamingStrategy 全局配置的适用边界
当项目中多数表都遵循同一套非默认规则（比如全部加前缀 tbl_、字段全用大驼峰），可以用全局 NamingStrategy 替代逐个写 TableName() 和 tag。
但它不适用于混合场景：比如大部分表用 tbl_ 前缀，但日志表必须是 log_records。此时强行统一策略反而增加维护成本，不如对特殊表单独实现 TableName()。
- 设置前缀：
&gorm.Config{NamingStrategy: schema.NamingStrategy{TablePrefix: "tbl_"}} - 禁用复数：
Pluralize: false（User→user而非users） - 字段名转换函数
ColumnName可自定义，但注意它会影响所有字段，包括外键和关联字段
关联字段（foreign key）的映射容易被忽略
一对多或 belongs-to 关系中，GORM 默认生成的外键字段名（如 user_id）也受命名策略影响。如果你手动指定了 UserID uint 字段并加了 gorm:"column:owner_id"，但没同步告诉 GORM 这是外键，它仍会尝试用 user_id 去 join —— 导致查询为空或报错。
解决方式是显式声明关系和外键：
type Order struct {
ID uint `gorm:"primaryKey"`
UserID uint `gorm:"column:owner_id"`
User User `gorm:"foreignKey:UserID;constraint:OnUpdate:CASCADE,OnDelete:CASCADE"`
}
这里 foreignKey:UserID 明确绑定到 struct 字段名（不是数据库列名），而 column:owner_id 控制实际存入哪一列 —— 两者需配合，不能只做一半。
外键字段的 tag 顺序无关紧要，但 foreignKey 必须指向 struct 中已声明的字段名，且该字段类型要和关联主键一致。
