任务链（withChain/Bus::chain）保证顺序执行但不保证原子性回滚；推荐传ID而非模型实例，失败需人工补救，dispatchAfterResponse不能替代链式依赖。
任务链（withChain 或 Bus::chain）能保证顺序执行，但不能保证原子性回滚——前一个成功、后一个失败，前面的不会自动撤回。
用 withChain 还是 Bus::chain？
两者都行，但语义和控制粒度不同：
-
withChain是 Job 类上的实例方法，适合从某个具体任务出发“往后接”：比如SendNotificationJob::dispatch()->withChain([new LogActivityJob, new UpdateStatusJob]) -
Bus::chain是总线级静态调用，更适合统一编排、不依赖起始 Job 类：比如Bus::chain([new ProcessPodcast, new OptimizePodcast])->dispatch() - 若链中某任务需指定队列（如通知走
high、报表走reports），withChain无法动态设置，必须提前在任务构造时调用onQueue('high')；Bus::chain同理，每个任务实例得自己带好队列配置 - 两者都不支持在链式调用时传中间件——中间件只能写死在任务类的
$middleware属性里
参数怎么传才安全？别序列化模型或连接
链式任务之间靠 PHP 序列化传递参数，所以构造函数里只接受基础类型或可序列化的 DTO：
- ✅ 推荐：只传 ID，比如
public function __construct(public int $orderId)，然后在handle()里查Order::findOrFail($this->orderId) - ❌ 避免：在构造函数里调
$order->load('items')或$order->toArray()——这会让任务变重，且可能因数据库连接关闭而失败 - ❌ 绝对禁止：传
$this->connection、闭包、resource、Eloquent 模型实例（未转数组/ID）——序列化会炸，日志里看到Serialization of 'Closure' is not allowed - 多个关联 ID？用数组或轻量 DTO 封装：
new ProcessInvoiceJob(['order_id' => 123, 'user_id' => 456])，字段保持标量
链式任务失败后，怎么排查和补救？
链一旦中断，后续任务根本不会进队列，但前面成功的任务已执行完毕，Laravel 不提供回滚机制：
- 错误日志默认记录在
storage/logs/laravel.log，搜索关键词App\Jobs\YourJobName和异常堆栈即可定位失败点 - 想让失败时触发告警，不要依赖链式回调——它只在整条链跑完才执行；改用
failed()方法，在任务类里定义：public function failed(Throwable $exception) { \Log::error('Job failed', ['job' => get_class($this), 'exception' => $exception->getMessage()]); } - 补救手段只有人工干预：查 DB 状态、手动 dispatch 缺失任务、或重跑整个链（注意幂等性）
- 若任务 A 成功但 B 必须执行（比如发通知失败要兜底短信），别指望链式机制——得在 A 的
handle()里加try/catch，捕获 B 的异常后显式 dispatch 短信任务
为什么 dispatchAfterResponse 不能替代任务链？
这是最常踩的坑：以为“A 完了再触发 B”就该用 dispatchAfterResponse，其实完全不是一回事：
-
dispatchAfterResponse(new BJob)只是把 B 延迟到响应发出后执行，**不等待 A 是否成功、不感知 A 的返回值、也不保证顺序** - A 失败抛异常，B 依然会执行；A 成功但耗时久，B 可能比 A 先进队列（取决于事件循环）
- 真正需要依赖执行，唯一可靠路径是：在 A 的
handle()末尾直接dispatch(new BJob($data))，或用Bus::chain显式声明顺序 - 如果 A 和 B 跨服务或需强隔离，那就得上数据库状态表或 Redis 信号量——链式只是同队列内的轻量顺序工具
事情说清了就结束。真正麻烦的不是语法怎么写，而是想清楚「哪个任务该负责状态持久化」「失败时谁来清理中间产物」「监控时如何把 A 和 B 的日志串成一条链路」——这些设计决策，比选 withChain 还是 Bus::chain 重要得多。
