GORM 使用踩坑：N+1、事务与软删除

GORM 能让你很快写出 CRUD，也会在「看起来正常」的代码里埋下性能与一致性问题。博客这种读写不均的系统，最容易踩的三类坑是：N+1 查询、事务边界不清、软删除带来的唯一约束错觉。ORM 的价值是减少样板代码，不是替你思考数据访问形态——下面把踩坑现场和改法写具体一点。

N+1：列表页的隐形税

典型写法是先查文章列表，再在循环里取标签或作者：

var articles []Article
db.Where("status = ?", "published").Find(&articles)
for i := range articles {
    db.Model(&articles[i]).Association("Tags").Find(&articles[i].Tags)
}

这会变成 1 + N 次查询。十条文章还好，一百条再加上标签表连接，延迟和连接占用就会难看。正确做法是预加载：

db.Preload("Tags").
    Where("status = ?", "published").
    Order("published_at desc").
    Limit(10).
    Find(&articles)

预加载也有边界。详情页需要深层关联时再按需 Preload；列表页只拿展示字段，避免把 Markdown 正文一并拉出来。Select 限制列，比默默 SELECT * 更稳：

db.Select("id", "title", "slug", "summary", "cover_image", "published_at").
    Preload("Tags", func(tx *gorm.DB) *gorm.DB {
        return tx.Select("id", "name", "slug")
    }).
    Find(&articles)

排查时打开 SQL 日志或使用慢查询统计，观察是否出现「相同模式的短查询密集出现」。那就是 N+1 的气味。很多「接口偶尔变慢」最终不是复杂 SQL，而是循环里悄悄打出去的几十次小查询。

事务：要么一起成功，要么一起失败

「创建文章 + 绑定标签 + 写操作日志」如果分三次提交，中途失败会出现半成品数据。应当显式事务：

err := db.Transaction(func(tx *gorm.DB) error {
    if err := tx.Create(&article).Error; err != nil {
        return err
    }
    if err := tx.Model(&article).Association("Tags").Replace(tags); err != nil {
        return err
    }
    return nil
})

事务里不要做不可回滚的外部副作用（发邮件、调第三方支付）——那些需要「最终一致」思路，而不是塞进同一个 DB 事务。事务时间也要短：先准备好内存数据，再进事务写库，不要边远程调用边占着事务。连接池被长事务占满时，表现会像「网站卡住了」，但表面错误信息可能只是获取连接超时。

还要注意：事务回调里必须使用传入的 tx，而不是外层的全局 db。混用会导致你以为在事务中，实际部分语句已自动提交，排障时非常折磨人。

软删除与唯一索引

GORM 的软删除给 deleted_at 赋值，默认查询会自动过滤。听起来贴心，却经常和唯一索引打架：用户删了再创建同名 slug，数据库仍认为旧行存在，于是唯一约束报错。

常见解法：

唯一索引改成「未删除范围内唯一」，例如 (slug, deleted_at) 并约定删除时写入精确时间戳
或删除后改写 slug（加后缀），释放原唯一键
或对真正需要物理清除的数据，用 Unscoped 删除并明确产品语义

「删除」在产品上到底是下架、回收站还是销毁，要先定义清楚，再映射到软删 / 硬删。后台列表若要看已删除内容，需要显式 Unscoped 或单独查询条件；忘记这一点时，你会觉得「数据没了」，其实只是默认作用域把它藏起来了。

零值与更新陷阱

用结构体更新时，零值字段可能被忽略。想把布尔值改成 false、数字改成 0，更稳妥的方式是 map[string]interface{} 或明确指定列。否则你会看到「前端传了 false，库里还是 true」。这不是前端 bug，是 ORM 更新语义。

// 危险：IsTop=false 可能更新不生效
db.Model(&article).Updates(article)

// 更明确
db.Model(&article).Updates(map[string]interface{}{
    "is_top": false,
    "status": "published",
})

指针字段可以区分「未传」与「传了零值」，但会让模型变复杂。后台管理系统字段通常明确，优先用 map 更新关键开关字段。部分更新接口更要把「可更新字段白名单」做死，避免客户端塞入 id、created_at 一类字段被意外写入。

迁移与模型漂移

AutoMigrate 适合早期快速原型，不适合作为唯一生产迁移手段。它能加列，却不擅长安全地删列、改类型、加复杂索引。生产环境应有可审查的迁移脚本，并区分「可回滚」与「不可回滚」变更。

模型标签（uniqueIndex、index）变更后，确认真实数据库是否出现预期索引；不要假设标签改了，库就自动对上。本地、预发、生产三套库结构不一致时，GORM 「在我机器上能跑」几乎没有参考价值。

调试阶段可以临时打开 SQL 打印，但生产要关掉或只对慢查询采样，否则日志量会淹没真正的错误信号。

小结

GORM 是加速器，不是自动驾驶。列表预加载、写路径事务、软删除与唯一约束的产品定义、零值更新语义——把这几件事写进团队习惯，博客这类中小系统也能稳住。性能问题大多不是 MySQL 「不行」，而是 ORM 帮你写出了看起来优雅、实际很贵的访问模式。先让 SQL 变得可见，再谈优不优雅。

GORM 使用踩坑：N+1、事务与软删除

GORM 使用踩坑：N+1、事务与软删除

N+1：列表页的隐形税

事务：要么一起成功，要么一起失败

软删除与唯一索引

零值与更新陷阱

迁移与模型漂移

小结

评论