GORM v2 中禁用复数表名必须在 gorm.Config 的 NamingStrategy 中设 SingularTable: true，db.SingularTable(true) 已被移除且编译报错；SingularTable 仅影响主模型表名，不控制中间表、外键及字段名，后者需显式配置或重写 TableName()。
默认开启复数表名是 GORM 最常踩的坑之一，禁用它必须在 gorm.Config 的 NamingStrategy 中显式设置 SingularTable: true，而不是调用旧版 API 或漏掉结构体嵌套层级。
为什么 db.SingularTable(true) 在 GORM v2 里完全无效
GORM v1 确实支持 db.SingularTable(true) 这种链式调用，但 v2 已彻底移除该方法。如果你在 v2 项目里写这行代码，编译会报错：类型 *gorm.DB 没有 SingularTable 方法。v2 的命名策略必须在初始化时通过 gorm.Config 一次性声明，之后不可修改。
- 错误写法：
db, err := gorm.Open(dia, &gorm.Config{}); db.SingularTable(true) - 正确时机：只能在
gorm.Open的第二个参数中配置 - 注意包导入：
gorm.io/gorm/schema必须引入，否则schema.NamingStrategy无法识别
NamingStrategy 中 SingularTable 和 NoLowerCase 的实际影响
SingularTable: true 只控制表名是否加 s/es，不影响字段名；而 NoLowerCase: true 会阻止字段名转小写下划线（比如 UserEmail → UserEmail 而非 user_email），但多数 MySQL 表设计仍依赖蛇形命名，所以一般不启用它。
-
SingularTable: true→User{}对应表user（不是users） -
SingularTable: false（默认）→User{}对应表users -
NoLowerCase: true+UserEmail string→ 列名变成UserEmail，可能触发 MySQL 大小写敏感问题 - 字段名转换由
schema.NamingStrategy的ColumnName函数控制，但改它会影响所有字段（含外键），慎用
已有数据库表名不匹配时，优先用 TableName() 而不是全局禁用复数
当项目已存在大量历史表（如 profile、order），且你只希望个别模型绕过复数规则，直接在结构体上实现 TableName() 方法更安全、更精准，不会干扰其他模型。
- 示例：
func (User) TableName() string { return "user" } - 这个方法的优先级高于
NamingStrategy.SingularTable，会直接覆盖全局设置 - 适合混用规范：新模块用单数表名，老模块保留
users、orders等复数名 - 注意：如果用了
TableName()，AutoMigrate会操作你指定的表名，别拼错
关联表和中间表的复数行为容易被忽略
即使你设置了 SingularTable: true，GORM 对 many2many 中间表的默认命名仍可能出错——它会把 User 和 Role 关联生成 user_roles，而不是 user_role。这不是 bug，是 GORM 明确设计的「关联表永远复数」逻辑。
- 解决中间表名不匹配：必须显式定义中间模型（如
UserRole），并在gorm:"many2many:user_role;"中指定表名 - 外键列名（如
user_id/role_id）也要靠joinForeignKey和joinReferences显式声明，不能依赖自动推导 - 别指望
SingularTable能统一管住所有表名，它只作用于主模型对应的基础表
真正麻烦的从来不是怎么关掉复数，而是关掉之后发现关联字段、中间表、外键列名全都不按预期走——这些地方没显式声明，GORM 就会按自己那套“合理但不兼容”的默认规则硬来。
