laravel队列任务中事务未回滚，主因是常驻进程复用连接导致事务污染；应严格限制db::transaction()作用域、改用手动try-catch控制、剥离副作用至观察者、增加幂等校验，并对齐retry_after与数据库wait_timeout。
如果您在 Laravel 队列任务中执行数据库写入操作，但发现事务未按预期回滚、数据不一致或报错“Transaction already active”，则很可能是由于队列进程的长生命周期与 Laravel 默认事务行为冲突所致。以下是解决此问题的步骤：
一、避免在队列任务中使用全局事务包装
Laravel 队列 worker 是常驻进程，复用同一应用实例；若在 handle() 外层包裹 DB::transaction()，事务连接可能被复用污染，导致锁表、连接超时或嵌套事务异常。应仅在真正需要原子性的最小代码块内开启事务。
1、打开任务类的 handle() 方法，定位到涉及多表写入或强一致性校验的逻辑段落。
2、将 DB::transaction() 包裹范围严格限制在具体业务操作内部，例如：DB::transaction(function () { $order->update(['status' => 'paid']); $log->save(); });
3、移除 handle() 方法顶部或整个方法体外的 DB::transaction() 调用。
二、手动管理事务并捕获异常后显式回滚
当需精细控制事务边界（如跨多个模型保存+第三方调用失败需整体回退）时，应弃用自动事务回调，改用 try-catch + 手动 begin/commit/rollback，确保异常发生时连接状态可控。
1、在 handle() 方法开头调用 DB::beginTransaction()。
2、执行所有数据库操作，包括模型 save()、update()、delete() 等。
3、在成功路径末尾调用 DB::commit()。
4、在 catch 块中调用 DB::rollback()，并确保抛出原始异常或记录错误日志。
5、务必在 finally 块中检查 DB::transactionLevel() > 0 并执行 rollback，防止因未捕获异常导致连接残留事务状态。
三、使用模型事件或观察者替代事务逻辑
对于非强一致性场景（如发送通知、更新统计字段），可将副作用操作剥离至模型事件监听器，在事件触发时单独开启短生命周期事务，避免主任务事务膨胀。
1、在任务 handle() 中仅执行核心业务变更，例如 $user->increment('points')。
2、为 User 模型注册观察者，在 updated 事件中处理关联通知：User::updated(function ($user) { DB::transaction(fn() => Notification::create([...])); });
3、确保观察者中事务不依赖 handle() 中未序列化的上下文对象（如 $request 或 session）。
四、对关键操作实施幂等性校验而非依赖事务回滚
队列任务独立于请求生命周期，无法继承原事务上下文；对支付确认、库存扣减等关键操作，应以幂等键（如 order_id + action_type）为依据，在执行前查重，避免重复处理引发的数据错乱。
1、在任务构造函数中传入不可变标识，例如 public function __construct(string $orderId, string $actionType) { $this->orderId = $orderId; $this->actionType = $actionType; }
2、handle() 中先查询 logs 表是否存在相同 orderId 和 actionType 的成功记录。
3、若存在，直接 return 跳过执行，不进入任何事务块。
4、若不存在，再执行业务逻辑并插入幂等日志记录。
五、配置 retry_after 与数据库 wait_timeout 对齐
MySQL 驱动下，若任务执行时间超过数据库 wait_timeout，事务连接会静默断开，导致 commit 失败但无明确异常；此时必须确保 retry_after 小于该值，使任务在连接失效前被释放重试。
1、执行 SHOW VARIABLES LIKE 'wait_timeout'; 获取当前 MySQL 连接空闲超时秒数。
2、在 config/queue.php 的 database 驱动配置中，将 'retry_after' 设为该值减去至少 10 秒，例如 'retry_after' => 290;
3、Redis 驱动不受此限制，但需确保 config/queue.php 中 redis.retry_after 与业务最大耗时匹配。
