如何在ThinkPHP中实现软删除数据的恢复_restore方法与内置事件触发

先说几个核心判断：ThinkPHP 的 restore() 方法之所以静默失败，十有八九是软删除字段没配置对，或者在模型中忘了开事件监听。更关键的是，恢复操作不会自动把关联数据也带回来——这点很多人踩过坑，但官方文档其实说得很明白，只是没强调罢了。

软删除字段没设对，restore() 会静默失败

restore() 只对启用了软删除的模型有效，但前提是模型必须明确声明软删除字段和值。假设数据库字段是 delete_time，模型里却没配或者配错了字段名，调用 restore() 不报错也不恢复——它直接跳过处理，像个哑巴。

具体怎么配？注意这几点：

• 模型类里必须写 protected $deleteTime = 'delete_time';，字段名要和数据库完全一致
• 如果用了时间戳类型（比如 datetime），确保字段允许为 NULL；如果是布尔型（比如 is_deleted），则还需配置 protected $type = ['is_deleted' => 'boolean']; 以及 protected $deleteTime = 'is_deleted';
• 检查模型是否继承自 think\Model，并且没有手动禁用软删除——比如写了 protected $autoWriteTimestamp = false; 却忘了配 $deleteTime，这种情况最容易悄无声息地翻车

restore() 不触发 before_restore 或 after_restore

很多人以为写好事件监听就能自动响应 restore()，结果回调压根没执行。原因很简单：ThinkPHP 默认不开启软删除事件监听，得显式启用才行。

解决方式如下：

• 模型里加上 protected $event = ['before_restore', 'after_restore'];
• 事件方法名必须严格匹配，比如 beforeRestore() 和 afterRestore()，驼峰命名，首字母小写
• 注意作用域：事件只在模型实例调用 restore() 时触发，比如 $user->restore()；如果是静态调用 UserModel::where('id', 1)->restore()，事件依然会触发，但得确保查询结果是模型对象，不是数组
• 如果用 Db 类直接操作，比如 Db::name('user')->where(...)->update(['delete_time' => null])，那事件完全不会触发——本质上它就是一个普通更新，跟 restore() 无关

批量恢复时 restore() 返回值和实际行为不一致

调用 UserModel::where('delete_time', 'not null')->restore() 看似合理，但返回值可能是 true，而实际只恢复了部分记录，甚至一条都没动。原因在于 ThinkPHP 的批量 restore() 底层走的是 update，但它不会校验 WHERE 条件是否真的命中了软删除数据。

怎么处理这种情况？

• 先查出待恢复的主键 ID 列表，然后一个个调用实例的 restore()。适合数据量小、需要触发事件的场景
• 追求性能的话，改用 Db::name('user')->where('delete_time', 'not null')->update(['delete_time' => null])，但要自己补日志或通知逻辑
• 务必确认 WHERE 条件能准确识别软删除状态：比如用 whereNotNull('delete_time') 比 where('delete_time', '', null) 更可靠
• MySQL 8.0+ 中 NULL 比较要用 IS NOT NULL，ThinkPHP 的 whereNotNull 会生成这个，别手写 SQL 片段

软删除恢复后关联数据不同步

restore() 只作用于当前模型表，不会递归恢复其关联模型。比如用户恢复了，但该用户的软删除订单仍处于删除态。这不是 bug，是设计使然——ThinkPHP 不做隐式级联。

如果业务上需要同步恢复，可以这样做：

• 在 afterRestore() 里手动处理关键关联，比如：$this->orders()->where('delete_time', 'not null')->update(['delete_time' => null]);
• 避免在关联模型里也定义软删除字段却忘了写同步逻辑，否则会出现“父存在、子不可见”的断裂状态
• 如果业务强依赖一致性，建议考虑把软删除粒度上移到聚合根层面，或者改用事务配合手动 SQL 控制恢复边界

软删除恢复不是“反向删除”，它本质上是一次带条件的更新操作。所有约束、索引、事件、关联都得按更新逻辑重新捋一遍。通常最容易忽略的两个坑是字段类型配置和事件开关——这两点没对，后面全白搭。