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 可能生成无条件语句，高风险场景下甚至误删全表。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 单条删除推荐先
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()，否则漏掉已删数据
恢复软删除记录，别用 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 钩子同步，这些细节一旦漏掉，线上就容易对不上数或还原失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
