Go mod 好菜系列 - 0x02 Gorm 这盘 ORM 到底怎么吃

详细拆 gorm 的定位、模型定义、迁移、CRUD、查询链、关联和事务，看看它为什么常见、又为什么经常引发争议。

Fuyu Jia

12 Apr 2026 — 4 min read

只要一聊 Go 数据库生态，gorm 基本很难绕过去。有人觉得它真香，能省掉一大堆 SQL 模板劳动；也有人嫌它太重、太黑盒、容易把查询性能搞成谜语。两边都不算完全错，关键在于你得先知道它是个什么东西。

gorm 是干嘛的

它是一个 ORM。简单说，就是把数据库表和 Go 结构体做了一层映射，让你能更多地用 Go 代码操作数据，而不是每次都从零手写 SQL。

它最典型能帮你做的事包括：

模型定义
CRUD
条件查询
关联关系
自动迁移
事务

为什么 gorm 常见

因为很多业务项目都有类似需求：表不少、模型多、增删改查重复劳动多。如果你全手写 SQL，当然更可控，但也确实更容易累。gorm 刚好填了这个“开发效率优先”的位置。

一个最基础的模型

type User struct {
    ID        uint           `gorm:"primaryKey"`
    Name      string         `gorm:"size:64;not null"`
    Email     string         `gorm:"uniqueIndex"`
    CreatedAt time.Time
    UpdatedAt time.Time
}

gorm 默认会根据结构体推表名、推字段，也会自动识别一些常见约定，比如主键、时间字段。

连接数据库

dsn := "user:password@tcp(127.0.0.1:3306)/demo?charset=utf8mb4&parseTime=True&loc=Local"
db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})
if err != nil {
    return err
}

如果你前面学过 database/sql，这里可以把 gorm 理解成“站在它上面的一层更高抽象”。底层很多事还是那套数据库驱动和连接池逻辑。

自动迁移很好用，但别无脑全信

err := db.AutoMigrate(&User{})
if err != nil {
    return err
}

这一步在开发环境里非常顺手，改个字段就能快速把表结构推过去。但到了正式环境，涉及大表变更、索引调整、数据迁移的时候，别把 AutoMigrate 当神仙按钮。复杂变更还是建议显式管理。

CRUD 写法为什么让人上头

user := User{Name: "Raymond", Email: "ray@example.com"}
if err := db.Create(&user).Error; err != nil {
    return err
}

var result User
if err := db.First(&result, 1).Error; err != nil {
    return err
}

if err := db.Model(&result).Update("name", "Ray").Error; err != nil {
    return err
}

if err := db.Delete(&result).Error; err != nil {
    return err
}

这类写法的优点非常直观：模型感强，样板少，读起来像“我要干什么”，而不是“我要拼哪句 SQL”。

查询链是 gorm 的日常主战场

var users []User
err := db.Where("age > ?", 18).
    Order("created_at desc").
    Limit(20).
    Find(&users).Error

这也是 gorm 让人觉得“效率高”的关键之一。它把很多条件组合写成了链式风格，适合日常业务查询。

关联关系也常见

type User struct {
    ID    uint
    Name  string
    Posts []Post
}

type Post struct {
    ID     uint
    Title  string
    UserID uint
}

var user User
err := db.Preload("Posts").First(&user, 1).Error

Preload 很好用，但也很容易让人不知不觉查出一大堆数据。关联一多，链路一深，性能就开始变玄学。所以能方便，不代表能放飞。

事务也照样能写

err := db.Transaction(func(tx *gorm.DB) error {
    if err := tx.Create(&User{Name: "A"}).Error; err != nil {
        return err
    }
    if err := tx.Create(&User{Name: "B"}).Error; err != nil {
        return err
    }
    return nil
})

这个 API 用起来很顺，而且可读性不错。对很多业务场景来说，这层封装是加分的。

gorm 最常被吐槽什么

生成 SQL 不够透明
复杂查询写着写着还是得掉回原生 SQL
关联多了以后很容易搞出性能问题
团队成员如果不懂底层 SQL，容易“会用但不知后果”

所以 gorm 的正确使用姿势从来不是“我再也不用懂 SQL 了”，而是“我用它提高常规开发效率，但底层 SQL 依然得懂”。

什么时候适合用 gorm

中小型业务系统
CRUD 很多、模型很稳的场景
想提高研发效率
团队能接受 ORM 约定

如果你做的是极度复杂、极度性能敏感的查询服务，那 gorm 未必是最优解，甚至你可能最后会混用原生 SQL。

小结

gorm 是一盘很常见的菜，但吃法得对：

它能明显提高常规数据层开发效率
模型、查询链、关联、迁移都很顺手
方便不等于可以不懂 SQL
复杂查询和性能敏感场景别闭眼全靠 ORM

下一篇我们换一道偏基础设施的菜：go-redis。数据库写慢了以后，很多项目下一步都会想碰它。