事务回滚失败主因是数据库引擎非InnoDB或异常未穿透事务闭包；需确认表引擎为InnoDB，确保异常抛出而非捕获后静默，避免事务中执行HTTP请求等不可逆操作，并谨慎处理队列中的事务。
事务回滚失败，通常不是 Laravel 本身的问题，而是底层机制被忽略或误用。核心原因就两个：异常没真正“透出”事务闭包，或者数据库根本不支持事务（比如用了 MyISAM 引擎）。只要盯住这两点，90% 的回滚失效问题都能快速定位。
检查数据库表引擎是否为 InnoDB
这是最容易被跳过的前提。Laravel 的 DB::transaction() 在 MyISAM 表上完全无效——它不报错、不警告，但也不会回滚。哪怕你写了十层嵌套事务，数据照样写进去一半。
- 运行 SHOW TABLE STATUS LIKE 'users';，确认 Engine 列显示 InnoDB
- 如果显示 MyISAM，执行 ALTER TABLE users ENGINE=InnoDB;
- 更稳妥的做法是在迁移文件中显式指定：$table->engine = 'InnoDB';
- 云数据库（如阿里云 RDS、腾讯云 CDB）部分模板仍默认 MyISAM，不能只看文档，必须实查
确保异常穿透事务闭包
DB::transaction() 只在闭包内抛出未捕获的 Throwable 时才自动回滚。任何“吞掉”异常的操作都会让事务误判为成功。
- ❌ 错误写法：在闭包里用 try-catch 处理完日志后没 throw $e
- ❌ 错误写法：if (!$order->save()) { return false; } —— 返回 false 不等于抛异常
- ✅ 正确做法：业务校验失败时主动 throw new RuntimeException('库存不足')
- ✅ 正确做法：catch 后必须重新抛出，例如 catch (\Exception $e) { Log::error($e); throw $e; }
避免事务中混入不可回滚操作
HTTP 请求、队列分发、缓存清除、邮件发送等操作一旦执行就无法撤销。它们若发生在事务中，会导致“数据库已回滚，但通知已发出去”的数据不一致。
- 把第三方调用移出事务闭包，放到 DB::transaction() 之后
- Observer 或模型事件里的 DB 操作默认不在事务上下文中，需手动包裹进同一事务块
- 不要在事务里调用 Notification::send() 或 Http::post()，网络延迟还可能卡死连接池
- 如需强一致性，改用补偿事务（Saga）或最终一致性+重试机制
队列任务中事务要特别小心
队列 worker 是常驻进程，复用数据库连接。若事务未正常结束，残留状态会污染后续任务，出现“Transaction already active”或锁表问题。
- 禁止在 handle() 方法外层套 DB::transaction()
- 事务范围必须最小化，只包裹真正需要原子性的几行 DB 操作
- 推荐手动控制：DB::beginTransaction() → 执行 → DB::commit() / DB::rollback()，并在 finally 块中检查并清理残留事务
- 对齐 retry_after 配置与数据库 wait_timeout，防止连接被服务端主动断开
