Golang实现基于GORM的软删除机制和语言学习中的持久层设计

GORM软删除需DeletedAt为*time.Time类型并加gorm:"index"标签或嵌入gorm.Model，否则Delete()执行物理删除；默认查询自动过滤软删记录，查全部或恢复须用Unscoped()。

软删除在 GORM 中不是“加个字段就自动生效”，而是依赖 DeletedAt 字段的类型、标签和嵌入方式三者共同触发；用错类型或漏掉 gorm:"index"，Delete() 就会变成物理删除，查不到数据也找不到原因。

DeletedAt 字段必须是 *time.Time，不能是 time.Time

GORM 用 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。你“查不到”，恰恰说明软删除在工作。

立即学习“go语言免费学习笔记（深入）”；

• 要查含已删记录：必须前置 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 钩子同步，这些细节一旦漏掉，线上就容易对不上数或还原失败。