ThinkPHP的restore()方法静默失败主因是软删除字段未正确配置，需在模型中明确定义$deleteTime并启用事件监听，且恢复操作不自动同步关联数据。
软删除字段没设对，restore() 会静默失败
ThinkPHP 的 restore() 方法只对启用了软删除的模型生效，但前提是模型必须明确声明软删除字段和值。如果数据库字段是 delete_time，但模型里没配或配错，调用 restore() 不报错也不恢复——它直接跳过处理。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在模型类中必须定义
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 默认不开启软删除事件监听，需要显式启用。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在模型中添加
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 条件是否真命中了软删除数据。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 先查出待恢复的主键 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 不做隐式级联。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在
afterRestore()里手动处理关键关联，例如：$this->orders()->where('delete_time', 'not null')->update(['delete_time' => null]); - 避免在关联模型里也定义软删除字段却忘了同步逻辑，否则会出现“父存在、子不可见”的断裂状态
- 如果业务强依赖一致性，考虑把软删除粒度上移到聚合根层面，或改用事务 + 手动 SQL 控制恢复边界
软删除恢复不是“反向删除”，它本质是一次带条件的更新操作，所有约束、索引、事件、关联都得按更新逻辑重新捋一遍。最容易被忽略的是字段类型和事件开关——这两个点没对，后面全白搭。
