GORM v2中如何从任意结构体获取对应的数据库表名

GORM v2 移除了v1版本的NewScope接口后，不需要通过执行真实查询的取巧方式拿表名，直接调用框架原生的元数据解析能力即可，该方案会自动适配全局命名策略、结构体自定义TableName()方法、动态表名规则等所有场景，和框架内部CRUD时使用的表名解析逻辑完全一致，且无任何数据库IO开销。

通用封装方法 #

// GetTableName 解析任意结构体对应的GORM真实表名
// 参数db为已初始化的gorm DB实例，model为目标结构体指针
func GetTableName(db *gorm.DB, model interface{}) (string, error) {
    // 新建独立会话，避免解析操作污染原DB实例的会话状态
    stmt := &gorm.Statement{DB: db.Session(&gorm.Session{NewDB: true})}
    // 仅解析模型元数据，不会触发任何数据库交互
    if err := stmt.Parse(model); err != nil {
        return "", err
    }
    return stmt.Table, nil
}

使用示例 #

比如未实现TableName方法的普通User结构体：

type User struct {
    ID   uint
    Name string
}

// 调用获取表名
tableName, err := GetTableName(db, &User{})
// 使用默认蛇形复数命名策略时，返回值为 `users`

如果是链式调用场景，不需要额外封装，直接通过Model方法设置模型后读取即可，同样不会触发查询：

tableName := db.Model(&User{}).Statement.Table

方案优势 #

• 无额外开销：全程仅做内存中元数据解析，不会向数据库发送任何请求，性能和v1版本的db.NewScope(&User{}).TableName()持平
• 兼容性拉满：自动识别所有GORM支持的表名配置规则，包括全局自定义命名策略、结构体实现的TableName()方法、会话级临时表名配置、动态表名插件等，不会出现手动拼接表名和实际执行SQL表名不一致的问题
• 无副作用：解析时使用全新独立会话，不会修改原有DB实例的配置状态

注意：不要使用db.First(&Struct{}).Statement.Table这类取巧方案，该方式会真实执行SELECT查询，不仅有冗余IO，还可能因为表权限、空数据、表不存在等问题抛出和表名解析无关的异常。

内容的提问来源于stack exchange，提问作者Tom Anderson