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 钩子同步——这些细节一旦漏掉，线上就容易对不上数或还原失败。所以，软删除不只是加个字段那么简单，它需要你从一开始就规划好整个数据生命周期。
