不能直接在phpMyAdmin里恢复软删除数据，因其无Eloquent模型逻辑；必须通过Laravel模型实例调用restore()，才能触发事件、策略校验与关联处理，确保事务一致性和生命周期完整。
不能直接在 phpmyadmin 里“恢复”软删除数据——它没有 laravel 的模型逻辑，restore() 方法根本不存在。
phpMyAdmin 里改 deleted_at 字段为 NULL 不等于恢复
你在 phpMyAdmin 中手动把某行的 deleted_at 值设成 NULL，数据库层面确实清掉了时间戳，但 Laravel 下次查询时仍不会返回它，除非你显式调用 withTrashed() 或 onlyTrashed()。更关键的是：restore() 不只是清空字段，还会触发模型事件（如 restoring、restored）、检查策略、运行观察者逻辑——这些全被跳过。
- 手动设
NULL后，User::find(123)还是查不到，因为框架默认加了WHERE deleted_at IS NULL，而该条件在 SQL 层面成立，但模型生命周期已中断 - 如果模型里有
restored事件监听器（比如要同步更新统计表），它完全不会执行 - 关联数据（如
User的posts）不会自动重新关联或刷新状态
真正生效的恢复操作必须走 Eloquent 生命周期
只有通过 Laravel 的模型实例调用 restore()，才能保证字段更新、事件触发、事务一致性。phpMyAdmin 是纯 SQL 工具，不加载模型类、不解析 trait、不运行 boot() 方法。
- 正确做法：进
php artisan tinker，执行User::withTrashed()->find(123)->restore() - 批量恢复：用
User::onlyTrashed()->where('deleted_at', '>', '2026-01-01')->restore()，而不是在 phpMyAdmin 里拼 WHERE - 如果服务器没 CLI 权限，可临时写一个 Artisan 命令或 Web 路由（带权限校验），在 PHP 环境中执行恢复逻辑
为什么有人觉得“改 NULL 就行”？常见误解来源
这种错觉通常来自两个场景：
- 开发环境开了
DB::enableQueryLog()，看到 SQL 里UPDATE ... SET deleted_at = NULL，误以为这就是 restore 全部行为 - 前端页面缓存没清，改完
deleted_at后刷新还是看不到，就去查模型代码，发现漏写了use SoftDeletes，于是以为“只要字段对就能恢复” - 用
dd(User::all())测试时忘了加withTrashed()，看到空结果，就回头去数据库硬改——改完再跑dd()还是空，陷入死循环
最易被忽略的一点：软删除恢复不是原子操作，它依赖模型定义的完整上下文。绕过这个上下文，哪怕 SQL 看起来一样，也得不到等价结果。
立即学习“PHP免费学习笔记（深入）”；
