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 可能生成无条件语句，高风险场景下甚至误删全表，这可不是闹着玩的。

• 单条删除，推荐先 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()，否则漏掉已删数据

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

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

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

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