Golang语言学习：基于GORM的软删除机制与持久层设计

GORM软删除常见陷阱与避坑指南：从字段定义到数据恢复

先说个核心判断：GORM 的软删除并非简单加个字段就自动生效。它依赖于 DeletedAt 字段的类型、标签以及嵌入方式三者共同配合才能正确触发。哪怕类型写错、标签遗漏，Delete() 就会直接变成物理删除，导致数据查不到却不知道问题出在哪里。

很多人踩过这个坑：DeletedAt 字段必须是 *time.Time，不能是 time.Time

关键在于，GORM 如何判断一条记录是否已被软删除？它检查 DeletedAt 是否为 nil。nil 表示未删除，非 nil 才视为软删除。如果你将字段定义成 time.Time（值类型），新插入的记录 DeletedAt 默认是零值 0001-01-01 00:00:00 +0000 UTC，GORM 会误认为这条记录“已删除”，刚创建完就查不到，想想就令人头疼。

• ✅ 正确写法：DeletedAt *time.Time `gorm:"index"`
• ❌ 错误写法：DeletedAt time.Time 或 DeletedAt sql.NullTime
• 最省事的方案：直接嵌入 gorm.Model，它自带 *time.Time 类型的 DeletedAt 和索引，省心又不易出错

Delete() 没有软删除？先检查结构体是否有有效主键和 DeletedAt

有时候你调用 Delete()，发现数据直接消失了，而不是被标记为已删除。这里需要关注两点：模型里是否存在可识别的 DeletedAt 字段，以及传入对象的主键是否有效。如果主键是零值（比如 ID = 0），GORM 可能生成无条件的 DELETE 语句，高风险场景下甚至误删全表，这可不是闹着玩的。

• 单条删除，推荐先 First() 查出再 Delete()，避免传入零值 ID
• 批量删除，务必用 Where().Delete(&User{})，不依赖实例主键
• 如果 Delete() 日志里出现 DELETE FROM 而不是 UPDATE，说明软删除根本没有启用——八成是字段类型不对或未嵌入 gorm.Model

查不到软删除记录？不是 bug，而是默认行为

很多人遇到“查不到数据”就慌了，以为是代码写错了。实际上，GORM 所有常规查询方法（Find、First、Where().Find、Count）默认自动追加 WHERE deleted_at IS NULL。你“查不到”，恰恰说明软删除正在工作，它帮你过滤掉了已删除的记录。

• 要查询包含已删除的记录：必须前置 Unscoped()，例如 db.Unscoped().Where("name = ?", "foo").Find(&users)
• 只查询已删除的记录：db.Unscoped().Where("deleted_at IS NOT NULL").Find(&users)，注意字段名小写（deleted_at）
• Unscoped() 是链式调用，必须写在最前面，且影响整条链（包括 Preload 关联查询）
• 统计总注册数这类指标，别忘了用 Unscoped().Count()，否则会漏掉已删除的数据

恢复软删除记录，别用 Save()，要用 Update 设置 nil

恢复的本质是将 DeletedAt 设回 nil，但这不能靠 Save() 或手动赋值再 Save()——这样会跳过钩子，而且容易误写成 time.Time{}（零值时间仍被视为已删除）。

• ✅ 正确恢复：db.Unscoped().Model(&user).Where("id = ?", 123).Update("deleted_at", nil)
• ❌ 错误操作：user.DeletedAt = nil; db.Save(&user)（可能跳过 BeforeUpdate 钩子）
• ❌ 更危险：user.DeletedAt = time.Now() 或 user.DeletedAt = time.Time{}，前者等于重复软删除，后者零值被判定为已删除
• 物理删除（不可逆）：db.Unscoped().Delete(&user)，它绕过所有软删除逻辑和钩子

真正麻烦的不是怎么删，而是删完之后怎么查、怎么恢复、怎么与关联数据联动。Unscoped() 透传到 Preload、Count 默认不统计已删除、回收站需要额外表和 AfterDelete 钩子同步——这些细节一旦遗漏，线上就容易出现数据对不上或恢复失败。所以，软删除不只是加个字段那么简单，它需要你从一开始就规划好整个数据生命周期。