gorm软删除需满足三要素：deletedat必须为*time.time类型（推荐嵌入gorm.model）、删除必须用db.delete()而非原生sql、查询默认跳过已删记录，否则软删失效。
gorm.Model 的 DeletedAt 字段不是自动生效的
软删除在 GORM 中依赖 DeletedAt 字段触发，但前提是模型必须嵌入 gorm.Model（或手动定义 DeletedAt 为 *time.Time 类型），且使用 GORM 提供的删除方法（如 Delete）——直接 db.Exec("DELETE FROM...") 或原生 SQL 不会写入 DeletedAt，也不会跳过已软删记录。
常见错误是只加了字段没配行为：比如定义了 DeletedAt time.Time（非指针），GORM 无法区分“零值”和“未删除”，导致软删失效；或用了 db.Unscoped().Delete() 却忘了后续查询默认不带 Unscoped，结果查不到刚删的记录。
-
DeletedAt必须是*time.Time类型（推荐用gorm.Model自带的） - 删除必须走
db.Delete(&user)，不能用db.Where(...).Delete(&User{})（后者需显式传指针类型） - 查询默认自动忽略
DeletedAt IS NOT NULL的行，要查全部得加Unscoped()
软删除后关联查询仍可能返回脏数据
GORM 默认不会递归软删除关联表，也不会在预加载（Preload）时自动过滤已软删的关联记录。比如用户软删后，其 Orders 若也启用了软删除，db.Preload("Orders").Find(&user) 仍会把已软删的订单查出来。
这不是 bug，而是设计使然：GORM 把每个模型的软删逻辑隔离处理。想让预加载也遵守软删规则，必须对关联字段显式加条件：
立即学习“go语言免费学习笔记（深入）”；
db.Preload("Orders", func(db *gorm.DB) *gorm.DB {
return db.Unscoped().Where("deleted_at IS NULL")
}).Find(&user)
- 所有涉及关联的软删场景，都要检查
Preload和Joins是否绕过了DeletedAt过滤 -
HasOne/HasMany的外键约束不受软删影响，删主表记录后，子表记录仍存在（只是DeletedAt被设值） - 如果子表没定义
DeletedAt，它根本不会被软删 —— 软删不是级联行为
硬删（Unscoped().Delete）后无法恢复，且可能破坏外键引用
Unscoped().Delete 是真删，行从数据库物理消失。很多人误以为“先软删再硬删”是标准流程，但实际中容易踩两个坑：一是业务代码里混用 Delete 和 Unscoped().Delete 导致状态混乱；二是硬删主表记录后，若子表有外键指向它且未设 ON DELETE CASCADE，下次插入或更新可能报 foreign key constraint fails。
- 硬删前务必确认该记录无活跃关联（尤其日志、审计、统计类表常被忽略）
- 生产环境建议禁用裸
Unscoped().Delete，改用标记位（如IsPurged bool）+ 定期批处理清理 -
Unscoped()是全局开关，一旦调用，后续链式操作（包括Where、Order）都失去软删过滤能力，容易漏掉条件
自定义软删字段名时，SoftDelete 插件必须显式启用
如果你不用 DeletedAt 而是叫 IsDeleted 或 RemovedAt，GORM 不会自动识别——它只认 DeletedAt（且类型必须是 *time.Time）。想换字段名，得手动注册 SoftDelete 插件并指定列：
db.Use(softdelete.New(softdelete.Config{
DeletedAtField: "IsDeleted", // string 类型
}))
注意：这个插件要求字段是 bool 类型（如 IsDeleted bool），和原生 DeletedAt 的时间戳语义不同，查询逻辑也变了（变成 WHERE is_deleted = false）。
- 别混用两种风格：同一项目里既有
DeletedAt又有IsDeleted，会导致 GORM 行为不一致 -
softdelete插件需单独go get gorm.io/plugin/softdelete，老版本 GORM v1 没这功能 - 自定义字段名后，
Unscoped()依然有效，但过滤条件变成你指定的字段，不是默认的DeletedAt
DeletedAt 很容易变成“选择性可见”。 
