Laravel 任务链（Bus::chain）用于严格顺序执行且允许失败中断的后台任务，不提供事务回滚；适用于有明确因果关系的步骤（如生成缩略图→上传CDN→更新数据库），单链建议不超过4步并配监控告警。
任务链在 Laravel 里不是“语法糖”，而是队列任务间强依赖的落地方案——它不保证事务一致性，但能控制执行顺序和失败传播。用错地方（比如当成数据库事务）会埋下数据不一致的坑。
什么时候该用 Bus::chain() 而不是手动 dispatch()
当你有一组必须严格按序执行、且后一步依赖前一步输出（或状态变更）的后台任务时，Bus::chain() 才有意义。比如「生成缩略图 → 上传 CDN → 更新数据库 media 字段」，中间任意一步失败，后续不该跑。
- ✅ 适用：步骤有明确因果关系、允许失败中断、无需回滚已执行步骤
- ❌ 不适用：需要原子性（如扣库存+创建订单）、各步骤可并行、或依赖外部系统最终一致性（如调第三方 API 成功后才发通知）
- ⚠️ 注意：
Bus::chain()的每个任务仍是独立进程，彼此不共享内存；传参只能靠构造函数或数据库/缓存中转
withChain() 和 Bus::chain() 的关键区别在哪
两者都实现任务串联，但调用入口和灵活性不同：withChain() 是单个 Job 实例上的方法，适合从某个主任务出发追加依赖；Bus::chain() 是静态门面，更清晰、支持更多回调，是当前推荐方式。
-
withChain()必须从第一个任务实例发起，比如(new ProcessOrder($order))->withChain([...])，后续任务无法再追加链 -
Bus::chain([new A, new B, new C])->dispatch()更直观，还能链式挂->then()、->catch()、->finally() - 二者底层都走
Illuminate\Bus\Dispatcher，但Bus::chain()在失败时默认记录日志并停止，而withChain()的错误传播行为稍隐晦，容易漏处理
链式任务失败后，前面的任务会自动回滚吗
不会。Laravel 队列本身没有事务回滚机制。如果链是 [DeductStock, CreateOrder, SendSms]，第三步失败，前两步的数据库写入已生效，状态就脏了。
- 你得自己在每个任务的
handle()里做补偿逻辑，比如CreateOrder失败时主动调DeductStock::reverse() - 或者改用状态机 + 重试兜底：把整个链封装成一个带状态字段的模型（如
OrderProcessing），每步更新状态，失败后由单独的 watchdog 任务扫描并触发修复 - 别指望
catch()回调能“撤回”已执行任务——它只负责通知或记录，不具反向操作能力
怎么让链中任务共享上下文（比如 trace_id 或用户 ID）
不能靠闭包或临时变量传递。每个任务在独立进程中反序列化执行，唯一可靠的方式是显式注入或中心存储。
- 最简单：把必要参数全塞进每个任务的构造函数，例如
new LogActivityJob($userId, $traceId)，确保所有任务类都接收并存储这些值 - 更健壮：用 Redis 存临时上下文，key 命名为
chain:{$uuid}，前置任务写，后续任务读，记得设 TTL 避免堆积 - 日志追踪：配合
TraceIdProcessor和全局变量$GLOBALS['current_trace_id']，但在队列中需在每个handle()开头手动赋值，否则日志链路会断
真正难的从来不是怎么连起来，而是怎么定义清楚每一步的边界、失败含义和补救路径——链越长，人工干预成本越高。生产环境建议单链不超过 4 步，关键链必须配监控告警。
