11 KiB
11 KiB
tags, create time
| tags | create time | |||||||
|---|---|---|---|---|---|---|---|---|
|
2026-04-28 00:00 |
软删除
概述
软删除是一种「逻辑删除」策略——数据并没有真正消失，只是被标记为「已删除」。这是 Web 应用中处理「删除」操作的默认推荐方式，因为它提供了可恢复性和审计追踪能力。
flowchart TD
A["调用 db.Delete(&user)"] --> SoftDel["模型有 DeletedAt 字段?"]
SoftDel --> |否|"HardSQL[DELETE FROM users WHERE id = ? ⚠️ 物理删除，不可恢复]"
SoftDel --> |是|"UpdateSQL[UPDATE users SET deleted_at=NOW() WHERE id=? ✅ 保留数据]"
UpdateSQL --> Query{"常规查询?"}
Query --> |是| Filtered["WHERE deleted_at IS NULL\n已删除记录自动隐藏"]
Query --> |否| UnscopedQ["需要已删除数据?"]
UnscopedQ --> |是| IncludeAll["Unscoped() → 全部返回"]
UnscopedQ --> |否| Filtered
style SoftDel fill:#4FC08D,color:#fff
style Filtered fill:#3B82F6,color:#fff
style HardSQL fill:#EF4444,color:#fff
DeletedAt 机制
声明式启用
在 struct 中嵌入 gorm.Model 或显式声明 DeletedAt gorm.DeletedAt：
type User struct {
gorm.Model // 自动包含 ID, CreatedAt, UpdatedAt, DeletedAt
Name string `gorm:"size:64;not null"`
}
// 等价的手动声明（需 import "time"）
type Product struct {
ID uint `gorm:"primaryKey"`
Name string `gorm:"size:128;not null"`
Price float64 `gorm:"not null"`
CreatedAt time.Time
UpdatedAt time.Time
DeletedAt gorm.DeletedAt // 软删除字段
}
[!note] gorm.DeletedAt 的本质
gorm.DeletedAt是time.Time的类型别名，但它告诉 GORM 这是一个软删除标记。只有当这个字段存在时，GORM 才会开启软删除行为。
软删除 vs 物理删除
var user User
// ===== 软删除（推荐）=====
db.Delete(&user) // UPDATE users SET deleted_at=... WHERE id=?
// 查询时自动过滤：SELECT * FROM users WHERE deleted_at IS NULL AND id=?
// ===== 物理删除 =====
db.Unscoped().Delete(&user) // DELETE FROM users WHERE id=?
// 彻底擦除，无法恢复！
// ===== 根据条件批量物理删除（配合清理策略使用）=====
db.Unscoped().Where("deleted_at < ?", time.Now().AddDate(-90, 0, 0)).Delete(&User{})
// 彻底清除超过 90 天的软删除记录（注意用 Unscoped 否则查不到已删除行）
[!tip] 关键区别
db.Delete()→ UPDATE 语句，触发 BeforeUpdate / AfterUpdate 钩子db.Unscoped().Delete()→ DELETE 语句，触发 BeforeDelete / AfterDelete 钩子 两者走不同的钩子链，设计时需要考虑清楚业务逻辑该放在哪个钩子里。
查询已删除数据
Unscoped — 忽略软删除过滤
Unscoped() 会关闭 GORM 自动附加的 deleted_at IS NULL 条件，让所有查询都能看到已删除的数据：
// 查询所有用户（包括已删除的）
var allUsers []User
db.Unscoped().Find(&allUsers)
// SELECT * FROM users; -- 不再附加 deleted_at 条件
// 查找特定已删除的用户
var deletedUser User
db.Unscoped().Where("id = ? AND deleted_at IS NOT NULL", 42).First(&deletedUser)
// 统计已删除的记录数
var count int64
db.Model(&User{}).Unscoped().Where("deleted_at IS NOT NULL").Count(&count)
精确查询含/不含已删除数据
// 只查正常用户
db.Where("deleted_at IS NULL").Find(&users)
// 只查已删除用户
db.Where("deleted_at IS NOT NULL").Find(&deletedUsers)
[!tip] 为什么不用 Where + Unscoped？
Unscoped()是一个全局开关，一旦开启就影响当前链的所有后续操作：// ❌ 意外行为 —— Unscoped 后面的 Find 也不过滤 db.Where("name = 'john'").Unscoped().Find(&users) // SELECT * FROM users WHERE name = 'john'; -- 包括已删除的 john！ // ✅ 精确控制 db.Where("name = ? AND deleted_at IS NULL", "john").Find(&users)
软删除中的关联处理
HasMany / BelongsTo
软删除模型的关联查询默认也会过滤已删除的关联项：
type User struct {
gorm.Model
Name string
Orders []Order `gorm:"foreignKey:UserID"`
}
type Order struct {
gorm.Model
UserID uint
}
var user User
db.Preload("Orders").First(&user, 1)
// Preload 生成的 SQL 会自动加入 deleted_at IS NULL：
// SELECT * FROM orders WHERE user_id = 1 AND deleted_at IS NULL;
// 如果需要已删除的关联项，使用 Unscoped().Preload()
BelongsTo（反向）
BelongsTo 端同样受过滤影响——当通过子记录查询父记录时，如果父记录已被软删除，默认也不会被加载：
type Order struct {
gorm.Model
UserID uint
User User `gorm:"foreignKey:UserID"`
}
var order Order
db.Preload("User").First(&order, 1)
// 如果该 Order 对应的 User 已被软删除，User 字段将为空
ManyToMany
对于多对多关联，GORM 在操作中间表时也会考虑软删除状态：
// 给订单添加商品（如果商品已被软删除，默认不会关联）
product := Product{Name: "Go Programming"}
db.Model(&order).Association("Products").Append(&product)
// 如果要强制关联已删除的商品（需 import "gorm.io/gorm/clause"）
db.Model(&order).Clauses(clause.OnConflict{DoNothing: true}).
Association("Products").Append(&product)
[!question] 思考题 如果一个父记录被软删除，它的子记录（HasMany）还能被查询到吗？
答案：取决于查询起点。以未删除的父记录查询，子记录的软删除仍然生效；但如果你先 Unscoped 查到了已删除的父记录，再 Preload 其关联，子记录的软删除状态由 Preload 决定。
唯一约束与软删除冲突
这是软删除最常见的坑点——唯一约束检查在 UPDATE 之前执行，而旧记录仍然占着唯一值：
type Article struct {
gorm.Model
Slug string `gorm:"uniqueIndex;not null"` // 例如：my-first-post
}
// 第一次保存成功
db.Create(&Article{Slug: "my-first-post"})
// 更新 slug
db.Model(&Article{}).Where("id = ?", 1).Update("slug", "my-updated-post")
// UPDATE articles SET slug='my-updated-post', deleted_at=NULL WHERE id=1;
// ⚠️ MySQL 不会对已删除行检查唯一约束（InnoDB bug）
// ⚠️ PostgreSQL 和 SQLite 会报错：duplicate key value
解决方案
// 方案一：使用部分唯一索引（PostgreSQL 支持）
// CREATE UNIQUE INDEX idx_articles_slug ON articles(slug) WHERE deleted_at IS NULL;
// GORM 暂不直接支持部分索引，需手动执行 SQL
// 方案二：额外加一个版本字段
type Article struct {
gorm.Model
Slug string `gorm:"not null"`
SlugHash string `gorm:"uniqueIndex;not null"` // slug + 随机哈希
}
// 方案三：用复合唯一索引覆盖软删除标记
// 在数据库层面创建 (slug, is_deleted) 联合唯一约束
[!tip] 最推荐的方案 方案一（部分唯一索引）是 PostgreSQL 用户的首选，只需一条 DDL 语句即可完美解决。MySQL 用户推荐使用方案二——用一个
SlugVersion uint字段记录 slug 修改次数，保证同一 slug 不会同时出现在两条未删除记录中。
[!warning] 跨数据库行为不一致 MySQL 的 InnoDB 引擎在处理软删除行的唯一约束时存在历史缺陷，不同版本行为可能不同。不要依赖这种行为一致性，应在应用层做好校验。
恢复已删除数据
// 恢复单个记录
db.Model(&User{}).Where("id = ?", 42).Update("deleted_at", nil)
// UPDATE users SET deleted_at=NULL WHERE id=42;
// 批量恢复
result := db.Model(&User{}).
Where("deleted_at IS NOT NULL AND email LIKE '%@test.com'").
Update("deleted_at", nil)
fmt.Printf("恢复了 %d 条记录\n", result.RowsAffected)
[!note] 注意 UpdatedAt 的变化 恢复操作本质是一次
UPDATE，GORM 会自动将UpdatedAt设为当前时间。如果审计要求记录原始创建信息而非恢复时间，这是正常行为。如需区分「创建」与「恢复」时间，可自行增加RestoredAt字段。
生命周期钩子
软删除触发的是一条 UPDATE 语句，因此 BeforeUpdate / AfterUpdate 会正常执行：
type User struct {
gorm.Model
Name string
Email string
}
func (u *User) BeforeDelete(tx *gorm.DB) error {
// db.Delete() 走的是 UPDATE，不会触发 BeforeDelete
// 如果需要在此处做逻辑（如级联标记），需用 Unscoped().Delete()
return nil
}
func (u *User) AfterUpdate(tx *gorm.DB) error {
// 软删除发生时，这条钩子会被调用
if u.DeletedAt != nil {
fmt.Printf("用户 %s 被软删除\n", u.Name)
}
return nil
}
[!warning] BeforeDelete 在软删除时不会被调用 GORM 的默认
db.Delete()只发送 UPDATE SQL，不经过物理删除的钩子链。如果需要在删除前做业务校验（如检查关联记录），可以使用Unscoped().Delete()或者在应用层自行实现检查逻辑。
定时清理策略
软删除会导致数据无限膨胀，建议建立定期清理机制：
// cron 定时任务：每月清理 90 天前的软删除记录
func CleanSoftDeletedRecords(tx *gorm.DB) error {
cutoff := time.Now().AddDate(0, 0, -90)
models := []any{&User{}, &Order{}, &Product{}}
for _, model := range models {
tx.Where("deleted_at IS NOT NULL AND deleted_at < ?", cutoff).
Delete(model)
}
return nil
}
软删除决策图
flowchart TD
Start["执行删除操作"] --> TypeQ{业务需求}
TypeQ --> |可恢复 / 需审计| SoftDel["软删除 db.Delete()"]
TypeQ --> |合规要求 / 不需恢复| HardDel["物理删除 Unscoped().Delete()"]
SoftDel --> AfterSoft["查询时需要已删除数据?"]
AfterSoft --> |是| UnscopedOn["db.Unscoped()"]
AfterSoft --> |否| NormalQ["普通查询\n自动过滤"]
HardDel --> AfterHard["数据永久移除"]
style Start fill:#4FC08D,color:#fff
style SoftDel fill:#3B82F6,color:#fff
style HardDel fill:#EF4444,color:#fff
style UnscopedOn fill:#F59E0B,color:#000
常见坑点速查
| 问题 | 原因 | 解决方案 |
|---|---|---|
| 唯一约束冲突 | 旧软删除行仍占唯一值 | 加版本字段或用部分索引 |
| Unscoped 影响后续查询 | 开关是链式的 | 及时结束链或改用显式 Where |
| 预加载跳过已删除关联 | GORM 自动加 deleted_at 过滤 | 用 Unscoped + Preload 组合 |
| 软删除导致数据膨胀 | 没有定期清理策略 | 定时任务清理过期记录 |
| First/Take 找不到已删除记录 | 自动过滤了 deleted_at | Unscoped().First() |