RabbitMQ中任务超时进死信队列需同时配置队列级x-message-ttl、x-dead-letter-exchange及x-dead-letter-routing-key，三者缺一不可；Redis无原生死信机制，须业务层兜底实现。
PHP队列任务超时后自动进死信队列的关键配置
默认情况下，RabbitMQ 或 Redis 队列里的任务不会“自动死亡”或转入死信队列——必须显式启用死信机制并配对 TTL 与死信交换机。否则哪怕任务执行卡死、超时，也会一直堵在原队列里，导致后续任务积压、消费者假死。
以 RabbitMQ 为例，关键点在于三者必须同时生效：
-
x-dead-letter-exchange和x-dead-letter-routing-key要在声明队列时通过setArguments()设置，不能只在消息头里加 -
x-message-ttl建议设在队列级（而非单条消息），避免因生产端未设置expiration导致失效 - 死信交换机（如
delay_exchange）必须提前存在，且类型为direct或topic，不能是fanout
Redis 场景则完全不同：它没有原生死信支持，需靠 Worker 主动捕获异常 + 手动 rPush('dead_letter_queue', $task) 实现，超时判断依赖 set_time_limit() 或信号中断，不可靠。
Laravel Horizon / Laravel Queue 的 retry_after 配置陷阱
retry_after 不是“任务最长运行时间”，而是“从入队到允许重试的间隔”。它控制的是：若 Worker 进程崩溃或被杀，该任务多久后能被另一个 Worker 拿走重试。它和任务实际执行超时无关。
立即学习“PHP免费学习笔记（深入）”；
常见误用是把 retry_after 设成 60 秒，以为能防止任务跑太久——其实毫无作用。真正防超时得靠：
- Worker 启动时调用
set_time_limit(30)（注意 CLI 模式下默认是 0，即不限制） - 在任务逻辑里用
pcntl_alarm()注册超时信号（需启用 pcntl 扩展） - 数据库任务表中记录
started_at，每次循环检查time() - $started_at > 30
另外，retry_after 值必须小于 timeout（Supervisor 的 stopwaitsecs 或 systemd 的 TimeoutStopSec），否则进程被强制 kill 时，任务来不及标记为失败，直接丢失。
死信队列里的任务怎么捞回来重试？
死信队列不是垃圾桶，而是故障隔离区。直接清空或忽略会导致数据不一致（比如订单已扣库存但通知没发）。重试前必须确认两点：
- 原始队列的消费者是否已修复？比如是下游 API 临时不可用，还是代码有死循环
- 消息体是否含幂等字段（如
order_id、event_id）？没有就别盲目重投，可能重复扣款
安全做法是写一个独立的 CLI 脚本，从死信队列读出任务，校验幂等性后，再 publish() 回原队列或新重试队列，并记录 retry_count 字段。不要用 brPop + rPush 简单搬运——RabbitMQ 的死信消息头（x-death）会丢失，无法追溯失败路径。
Redis 做队列时，超时与死信只能靠业务层兜底
Redis 没有消息 TTL 透传、没有死信交换机、没有 ACK 语义。所有可靠性都得自己补：
- 任务入队时存一份到 MySQL 表，含
status、created_at、max_retry，用定时任务扫描超时未完成的记录 - Worker 执行前先
SET task_lock:123 "worker-abc" EX 60 NX，防止同一任务被多个进程争抢 - 失败后不是删掉任务，而是
HSET failed_task:123 status "timeout" at time() error "max exec time exceeded"
这听着麻烦，但小项目用 Redis 就是图快——一旦开始纠结超时、死信、重试，说明已经到了该换 RabbitMQ 的临界点。
