只有基于RabbitMQ死信队列或Redis ZSET的延迟队列方案能满足高并发、低漏检、强时效要求；扫表轮询和定时任务因延迟不可控、漏检风险高、重复执行隐患而不可靠。
ThinkPHP 8.0 实现订单30分钟未支付自动取消，关键不在“能不能做”，而在“是否可靠”。扫表轮询、定时任务、消息队列延迟投递——三种方式里，只有基于 RabbitMQ 死信队列或 Redis ZSET 的延迟队列方案能真正满足高并发、低漏检、强时效的生产要求。
为什么定时任务和扫表不可靠
ThinkPHP 自带的 think:timer 或系统级 Crontab 每分钟甚至每5分钟扫描一次订单表，存在三重硬伤：
- 延迟不可控：最小触发间隔为分钟级，实际超时可能达31分钟甚至更久
- 漏检风险高：脚本异常中断、数据库锁表、慢查询阻塞都会导致某批次订单被跳过
- 重复执行隐患：无幂等设计时，同一订单可能被多次取消，引发库存误退、通知轰炸等问题
RabbitMQ 死信队列是电商级首选
它不依赖轮询，而是让消息在队列中“原地等待”30分钟，到期后自动路由到死信交换机，由消费者精准处理。核心配置要点：
- 声明队列时必须设置
x-message-ttl=1800000（毫秒），且设在队列级别，不是单条消息 - 同时绑定
x-dead-letter-exchange=dlx.order和x-dead-letter-routing-key=order.cancel - 死信交换机类型为
direct，并绑定到真实消费队列order_cancel_queue - 投递消息时只发往普通队列（如
order_timeout_queue），绝不直接发给死信交换机
Redis ZSET 延迟队列更轻量易落地
适合中小项目或不想额外运维 RabbitMQ 的团队。本质是用时间戳作 score 存入有序集合：
立即学习“PHP免费学习笔记（深入）”；
- 下单成功时执行：
ZADD delayed_order 1720420200 order_12345（1720420200 是当前时间 + 1800 秒） - 独立守护进程每秒执行：
ZRANGEBYSCORE delayed_order -inf [now] LIMIT 0 100，取出后立刻ZREM - 消费逻辑需显式设置 PHP 时区：
date_default_timezone_set('Asia/Shanghai')，避免时间错位 - 失败任务应转入重试队列，而非简单丢弃，保证最终一致性
消费者必须常驻且幂等
无论是 RabbitMQ 还是 Redis 方案，消费者都不能挂载在 Web 请求生命周期里：
- 启动命令统一为：
php think queue:listen --queue=timeout_queue或自定义命令如php think rabbitmq:consume - 取消逻辑开头加数据库唯一索引或 Redis SETNX 锁，防止同订单被多进程并发处理
- 状态更新用原子操作：
UPDATE orders SET status = 'cancelled' WHERE id = ? AND status = 'unpaid' - 日志记录必须包含订单 ID 和触发时间戳，便于事后审计与问题回溯
