软删除恢复失败主因是混淆withtrashed()（仅查询可见）与restore()（真正改状态）；查不到软删数据需用onlytrashed()->find()且确保字段允许null、模型启用softdelete及正确配置deletetime。
软删除数据恢复失败，八成是因为没搞清 withTrashed() 和 restore() 的分工——前者只管“查得到”，后者才真正“改状态”。
查不到软删数据？先确认 onlyTrashed() 有没有链式调用对位置
默认查询（User::where('id', 123)->find()）会自动加 AND delete_time IS NULL，所以软删记录根本不会出现。这不是丢数据，是框架主动过滤。
-
User::onlyTrashed()->where('id', 123)->find()才能定位已软删的单条记录；必须写在find()或select()前，写成User::where(...)->onlyTrashed()->find()无效 - 如果模型没引入
SoftDeletetrait，或数据库字段不是DATETIME NULL/BIGINT NULL，onlyTrashed()返回空但不报错，容易误判为“数据没了” - 字段名不是默认
delete_time？得在模型里显式声明：protected $deleteTime = 'deleted_at';
restore() 静默失败？检查字段类型、$type 声明和 null 写入能力
restore() 是实例方法，调用后不抛异常，但可能什么都没做——最常见原因是数据库拒绝写入 NULL。
- 数据库字段必须允许为空：
delete_time DATETIME NULL，不能设NOT NULL DEFAULT '0000-00-00 00:00:00'，否则 MySQL 严格模式下会静默失败 - 若用整型时间戳（如
BIGINT），模型中必须加：protected $type = ['delete_time' => 'integer'];，否则null被转成字符串再强转为0，后续仍被判定为已删除 - 调用前务必验证存在性：
User::onlyTrashed()->where('id', 123)->value('id')返回非null再执行restore()，避免对空对象调用
批量恢复别信 restoreAll()——它在 TP5/6 里根本不存在
任何 User::restoreAll() 写法都会直接报错：Call to undefined method。这是网上混淆 TP3 封装或误传导致的典型坑。
- 想触发
restoring/restored事件（比如日志、权限重置）：先查集合再逐条调用User::onlyTrashed()->chunk(500, function ($items) { $items->each->restore(); }); - 只求快、不关心事件：绕过模型，用
Db直接更新Db::name('user')->where('delete_time', 'not null')->update(['delete_time' => null]) - TP6 支持模型级批量更新：
User::onlyTrashed()->update(['delete_time' => null])；TP5 不支持，必须用Db或循环
关联查询里恢复软删数据，withTrashed() 不会自动透传
父模型调用 User::withTrashed()->find(1) 只影响 User 本身，它的关联模型（比如 posts()）仍按自身规则过滤软删数据。
- 要在关联中也包含软删记录，必须在定义关联时加
->withTrashed()：public function posts() { return $this->hasMany(Post::class)->withTrashed(); } - 或查询时动态追加：
User::with(['posts' => function ($q) { $q->withTrashed(); }])->find(1) - 如果
Post模型没启用SoftDelete，withTrashed()无效且不报错，这点极易被忽略
真正麻烦的不是语法，而是字段类型、数据库约束、模型配置三者没对齐——哪怕只差一个 NULL 允许，restore() 就会变成“看起来成功了，其实啥也没干”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
