Go mod 好菜系列 - 0x02 Gorm 这盘 ORM 到底怎么吃
详细拆 gorm 的定位、模型定义、迁移、CRUD、查询链、关联和事务，看看它为什么常见、又为什么经常引发争议。
只要一聊 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).ErrorPreload 很好用，但也很容易让人不知不觉查出一大堆数据。关联一多，链路一深，性能就开始变玄学。所以能方便，不代表能放飞。
事务也照样能写
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。数据库写慢了以后，很多项目下一步都会想碰它。