GORM 默认不支持全局表名前缀，因NamingStrategy.TablePrefix仅作用于AutoMigrate和db.Table()，不参与Preload、JOIN等SQL构建；若模型实现TableName()则完全忽略该配置。
为什么 GORM 默认不支持全局表名前缀
GORM v2 的 TableName() 接口只作用于单个模型，没有内置的全局表名前缀配置。直接在 gorm.Config 里设 NamingStrategy 时，TablePrefix 字段确实存在，但它**仅影响通过 AutoMigrate 创建的表名，不影响手动指定的 TableName() 或关联查询中的表引用**——这点很容易被文档误导。
常见错误现象：AutoMigrate(&User{}) 生成了 myapp_users，但 db.Preload("Orders").Find(&users) 却去查 orders 表，报错 ERROR: relation "orders" does not exist。
- 根本原因是 GORM 在构建 JOIN、Preload、Count 等 SQL 时，仍用原始结构体名（如
Order）推导表名，绕过了NamingStrategy.TablePrefix -
TablePrefix只在AutoMigrate和db.Table("xxx")这类显式调用中生效 - 若模型已实现
TableName() string，则NamingStrategy完全被忽略
正确设置全局前缀：覆盖 NamingStrategy + 手动统一模型定义
必须同时满足两个条件才能让前缀贯穿所有场景（CRUD、Preload、Association、Count）：
- 初始化
gorm.DB时，传入自定义gorm.NamingStrategy，并设置TablePrefix - 所有模型结构体**不要实现
TableName()方法**，否则前缀失效 - 如果已有模型写了
TableName()，必须删掉，改用NamingStrategy统一控制
示例初始化代码：
db, err := gorm.Open(postgres.Open(dsn), &gorm.Config{
NamingStrategy: schema.NamingStrategy{
TablePrefix: "myapp_", // 注意末尾下划线需手动加
},
})
此时 User{} 对应表 myapp_users，Order{} 对应 myapp_orders，且 Preload("Orders") 也会自动拼成 myapp_orders。
Gin 路由中使用带前缀的模型时的常见陷阱
Gin 本身不参与 ORM 表名逻辑，但开发者常在 Handler 中误用硬编码表名或忽略关联字段的命名一致性：
- 在
db.Raw()或db.Table("users")中写死无前缀表名 → 应改用db.Table(&User{})或db.Table("myapp_users") - 外键字段名未同步调整：比如
UserID uint在Order模型中，GORM 默认找user_id字段，但如果数据库实际是myapp_users.id，而外键列叫myapp_user_id，就必须显式声明：UserID uint `gorm:"column:myapp_user_id"` - JSON 标签和数据库字段名混淆：Gin 绑定用
json:，GORM 用column:，二者不能混用
验证前缀是否真正生效的三个检查点
别只看 AutoMigrate 输出，要实测运行时行为：
- 启用 GORM 日志：
db = db.Debug()，执行db.Preload("Profile").First(&user)，观察日志中 JOIN 的表名是否带前缀 - 检查
db.Migrator().CurrentDatabase()返回的 DB 名，确认不是测试库干扰 - 对多对多关联表（如
user_orders），GORM 默认生成users_orders；加前缀后变成myapp_users_orders—— 若没生效，说明NamingStrategy未正确传递到关联表生成逻辑
最易被忽略的是：Gin 中的中间件或工具函数若复用了未配置前缀的 *gorm.DB 实例，会导致部分请求走错表。务必确保所有 db 实例来自同一初始化流程。
