Laravel任务链怎么用_Laravel链式任务方法【教程】

先说一个很容易踩的坑：千万别把 Bus::chain() 当成数据库事务来用。它只保证执行顺序，不保证任何形式的回滚。链里的任务一个接一个跑，假如写到第三步的时候崩了，前两步写入数据库的数据可不会自己撤回来——那些变更就实实在在地留在那里了。

什么时候必须用 Bus::chain() 而不是手动 dispatch()

任务链的适用场景其实很明确：只有当步骤之间存在强因果依赖，并且你完全能接受“失败即中断、不撤回”这个前提时，才值得用它。

✅ 典型的场景包括：生成缩略图 → 上传到 CDN → 更新 media 字段。后一步必须依赖前一步产出的文件 URL，缺了谁都不行。

✅ 再比如：发送支付回调通知 → 标记订单为已通知 → 推送消息到 WebSocket。这里的状态流转是不可逆的，中间一旦断掉，后面的任务就不该继续执行。

❌ 但扣库存加创建订单这种操作，讲究的是原子性，必须用数据库事务或者更成熟的 Saga 模式来兜底，任务链根本搞不定。

❌ 还有像邮件、信息、站内信这样的多个独立通知，它们彼此之间没什么依赖关系，完全可以并行执行。这时候用 Bus::batch() 反而更合适。

Bus::chain() 传参为什么不能传模型实例

这个问题其实很容易理解。每个任务都是在独立的队列进程里被反序列化后再执行的。模型实例后面拖着的关系、原始 SQL 查询器这些东西，PHP 序列化根本处理不了，直接报错：Serialization of 'Closure' is not allowed 或者 Connection lost。

✅ 正确的做法只有一个：只传 ID。比如 new ProcessOrder($orderId)，然后在 handle() 方法里老老实实用 Order::findOrFail($this->orderId) 去查。

✅ 如果需要传多个关联 ID，可以用数组或者 DTO 来封装，但要记住字段只能限制在 int、string、bool 这些基础类型上。

❌ 千万不要在构造函数里写 $order->load('items') 或者 $order->toArray()。这不仅加重了序列化的负担，还可能因为连接关闭而直接失败。

链中任务怎么共享 trace_id 或用户 ID

HTTP 请求里的 request()->id 或者 Auth::id()，在队列进程里是全部失效的。你不能靠闭包去捕获，也不能依赖全局变量，那都不靠谱。

✅ 最稳的方式：显式注入到构造函数里。比如 new NotifyUserJob($userId, $trace_id)，然后在日志处理器中统一注入 $this->trace_id。

✅ 如果是长链场景，更好的做法是把 $trace_id 存进 job_logs 表，用 $job->id 来做关联。这样能避免参数在任务之间层层透传。

❌ 千万别在 withChain() 里写 function () use ($userId) { ... }。闭包无法序列化，运行时会直接找不到上下文。

失败后怎么补救，而不是指望 catch()

->catch() 这个回调，它的设计意图只是记录日志或者发告警。它不会、也做不到帮你撤回已经执行完的任务。

⚠️ 举个典型的反例：如果你的链是 [DeductStock, CreateOrder, SendSms]，第三步失败了，前两步的数据库写入已经生效，数据状态就脏了。

✅ 补偿方案一：每个任务自己实现反向操作。比如 CreateOrder::reverse() 里主动恢复库存。

✅ 补偿方案二：改用状态机模型（比如 OrderProcessing），每一步都更新一个 status 字段。失败之后，由 watchdog 任务去扫描并触发修复流程。

❌ 不要天真地以为 ->catch(fn () => DB::rollback()) 能解决问题。队列里根本没有事务上下文，你调 DB::rollback() 的时候，压根没东西可以回滚。

说到底，真正的难点从来不是怎么把任务串起来，而是想清楚：如果哪一步失败了，谁来兜底？数据怎么才能回到一致的状态？Lara vel 本身不替你判断这些，它只提供执行顺序的控制权。而这份控制权，怎么用、用在哪里，才是真正考验功底的地方。