gorm中全局命名策略通过namingstrategy配置，影响所有模型的表名和字段名生成；单个字段可用gorm:"column:xxx"覆盖；关联外键名易被忽略，需确保tag与关联定义一致。
如何配置全局 NamingStrategy
全局命名策略在 gorm.Config 初始化时生效，影响所有模型的表名和字段名生成逻辑。它适合统一规范（如全部禁用复数、加固定前缀），但无法区分个别例外模型。
常见组合配置：
-
NamingStrategy: schema.NamingStrategy{TablePrefix: "tbl_", SingularTable: true}→ 表名不加s尾缀，且带前缀（User→tbl_user） -
NamingStrategy: schema.NamingStrategy{NoLowerCase: true}→ 字段名不转小写（UserID→USERID，非默认的user_id） -
NamingStrategy: schema.NamingStrategy{Pluralize: false}→ 强制单数表名（User→user）
注意：Pluralize: false 和 SingularTable: true 效果相同，但后者更直观；若同时设 TablePrefix 和 SingularTable: false，则前缀会加在复数形式上（tbl_users），容易误判。
怎样覆盖单个字段的列名映射
当全局策略无法满足某字段特殊需求（比如外键列名要与 legacy 系统对齐），必须用结构体 tag 显式覆盖，默认驼峰转蛇形规则将被跳过。
-
UserID uint `gorm:"column:stu_id"`→ 强制映射为stu_id列，不再转成user_id -
CreatedAt time.Time `gorm:"column:created_on"`→ 覆盖 GORM 内置的created_at映射 - 关联字段（如
AuthorID）若未加gorm:"column:..."，仍按命名策略生成外键列名，这点常被忽略
⚠️ 所有被 gorm:"column:xxx" 覆盖的字段，GORM 不再自动识别其语义（例如不会触发软删除、时间戳填充等行为），除非额外补全其他 tag（如 gorm:"column:deleted_at;type:datetime"）。
为什么 TableName() 方法比全局策略更灵活
混合命名场景（如大部分表用 tbl_ 前缀，但 log_records 必须原样保留）下，硬套全局策略会导致维护成本上升或逻辑冲突，此时应让特定模型自行实现 TableName() 方法。
- 方法签名必须是
func(*YourModel) string，返回值即为真实表名 - 示例：
func (LogRecord) TableName() string { return "log_records" } - 该方法优先级高于
NamingStrategy，且只影响当前模型，不影响其他结构体
注意：如果模型嵌套了其他结构体（如内嵌 gorm.Model），TableName() 仍需显式定义，否则仍走全局策略。
关联字段的外键名容易被忽略
GORM 自动生成外键列名时，依赖的是字段名 + 命名策略，而不是结构体名。比如：
-
AuthorID uint→ 默认外键列是author_id（不是user_id） -
AuthorID uint `gorm:"column:uid"`→ 外键列强制为uid，但关联查询时仍需确保Author模型的主键也是uid，否则Preload会失败 - 若用
foreignKey或referencestag 定义关联，外键列名由 tag 控制，不再受NamingStrategy.Column影响
最易出错的是：改了字段 tag 的 column，却忘了同步更新关联定义里的 foreignKey，导致 JOIN 查询字段不存在或匹配错误。
