软删除恢复需事务保障一致性：一、用db::transaction包裹restore()及关联操作；二、批量恢复需分片+每批事务；三、模型重写restore()强制事务执行；四、嵌套流程用savepoint细粒度回滚；五、事件监听器校验事务上下文。
如果您在 Laravel 中执行软删除恢复操作时遇到数据不一致、部分恢复或事件未触发等问题，很可能是由于未在事务中包裹关键步骤。软删除恢复虽是单字段更新，但涉及状态变更、关联逻辑与事件调度，需确保原子性。以下是保障事务一致性的具体方法：
一、使用 DB::transaction 包裹 restore() 调用
当恢复操作需联动更新其他表（如日志、统计、权限状态）时，必须将 restore() 与相关写入操作置于同一数据库事务中，防止中间状态残留。Laravel 的 restore() 方法本身不开启事务，需手动封装。
1、在控制器或服务类中引入 DB 门面：use Illuminate\Support\Facades\DB;
2、调用 DB::transaction() 并传入闭包函数：
3、在闭包内先通过 withTrashed()->find() 或 onlyTrashed()->where() 获取目标模型实例；
4、调用 $model->restore() 执行恢复；
5、紧接着执行关联更新，例如写入操作日志：AuditLog::create(['action' => 'restore', 'model_id' => $model->id]);
6、若任意步骤抛出异常，整个事务自动回滚，deleted_at 字段与日志均保持原状。
二、为批量 restore 显式启用事务并分片处理
批量恢复（如 Article::onlyTrashed()->where('status', 'draft')->restore()）虽内部执行单条 UPDATE，但若涉及数百条以上记录且需同步处理关联模型，直接调用可能因超时或内存溢出中断。此时应拆分为固定大小批次，并为每批启用独立事务。
1、定义每批数量，例如 $batchSize = 100；
2、使用 chunkById() 按主键分片查询软删除记录：Article::onlyTrashed()->where('status', 'draft')->chunkById($batchSize, function ($articles) {
3、在 chunk 回调内调用 DB::transaction()；
4、对当前批次调用 $articles->each->restore()；
5、同步更新该批次所有文章的关联 tags 表中 is_active 字段为 true；
6、事务结束，继续下一批，任一批失败不影响已成功批次，但可记录失败 ID 供重试。
三、在模型中重写 restore() 并集成事务钩子
若多个业务场景均需在 restore 前后执行固定逻辑（如校验唯一约束、触发自定义事件、更新缓存），可在模型中覆盖 restore() 方法，强制其运行于事务上下文中，并支持嵌套事务安全。
1、在模型类中添加 protected $restoringInTransaction = false; 防止重复事务嵌套；
2、重写 restore() 方法，检查 $this->restoringInTransaction 状态；
3、若为 false，则调用 DB::transaction() 并在闭包中设置 $this->restoringInTransaction = true，再执行 parent::restore()；
4、在事务闭包末尾调用 $this->fireModelEvent('restored', false) 触发 restored 事件；
5、最后将 $this->restoringInTransaction 重置为 false；
6、注意：此方式要求模型已配置 $dispatchesEvents = ['restored' => Restored::class]，否则事件不会广播。
四、结合 savepoint 实现条件回滚的细粒度控制
当恢复操作需嵌套在更长业务流程中（如订单退款+商品库存恢复+用户积分返还），而其中某环节失败仅需回滚 restore 及其直连操作，不波及其他已提交步骤，应使用保存点（savepoint）而非完整事务。
1、在主流程起始处执行 DB::transaction(function () use ($order) { ... });
2、在事务闭包内，调用 DB::beginTransaction() 创建 savepoint；
3、执行 $item->restore() 及其依赖更新（如 Inventory::where('item_id', $item->id)->increment('quantity')）；
4、若后续积分返还失败，调用 DB::rollback(); 回退至 savepoint，仅撤销 restore 与库存变更；
5、主事务仍可 commit 其他已成功步骤（如订单状态更新）；
6、关键限制：MySQL 必须启用 innodb_support_xa，且驱动版本 ≥ 8.0.23 才完全支持 savepoint 嵌套。
五、使用模型事件监听器绑定事务生命周期
若需在 restore 开始前预检约束（如邮箱唯一性）、失败后清理临时资源，可通过监听 restoring/restored 事件，在事件处理器中主动介入事务管理，但必须确保监听器本身不开启新事务。
1、在模型中声明 protected $dispatchesEvents = ['restoring' => ModelRestoring::class, 'restored' => ModelRestored::class];
2、创建 ModelRestoring 监听器，在 handle() 方法中调用 DB::transactionLevel() 判断是否已在事务中；
3、若 transactionLevel() === 0，抛出异常 “restore 操作必须在事务中执行”，阻止非事务调用；
4、在 ModelRestored 监听器中，仅执行只读操作（如发送通知、更新搜索索引），禁止任何写入；
5、所有监听器内禁止调用 DB::transaction()，否则将导致嵌套事务冲突；
6、验证方式：在测试中 assertDatabaseMissing('users', ['id' => 123, 'deleted_at' => null]) 与 assertDatabaseHas('audit_logs', ['action' => 'restore']) 必须同时成立。
