thinkphp 6.0 中定时任务与队列分工协作：定时任务用 crontab 触发 think 命令（需绝对路径、切换工作目录、重定向日志），队列用 think-queue+redis 实现可靠执行，任务类须定义 fire() 方法并手动 delete()，延迟队列依托 redis zset，组合使用提升高可用性。
ThinkPHP 6.0 的定时任务和队列不是替代关系，而是分工协作：定时任务决定“何时触发”，队列解决“如何可靠执行”。进阶实践的关键，在于厘清边界、规避静默失败、做好环境隔离与生命周期管理。
定时任务必须用 crontab 调用 think 命令
TP6 自身不提供守护式调度器，不能依赖 Web 请求或 while 循环模拟。crontab 是唯一稳定可靠的触发方式。
- 路径必须绝对化：crontab 不加载用户 shell 环境，PATH 极其有限。需明确写出 PHP 解释器路径（如 /www/server/php/74/bin/php）、项目根目录（cd /var/www/myapp）、think 入口（php think sync:order）
- 工作目录要切换：think 命令依赖自动加载机制和 config 目录，若未在项目根目录执行，会报 Class not found 或配置缺失
- 日志必须重定向：加 >> /tmp/cron-sync.log 2>&1 或在命令内用 trace() 写入 runtime/log/cron/ 下专用文件，避免失败无迹可寻
- 测试先用 * * * * *：每分钟执行一次，观察日志是否生成，确认整个链路（crontab → PHP → think → 业务逻辑）畅通后再调整为真实周期
队列必须用 think-queue + Redis 驱动
sleep 循环、自建 while 消费、数据库轮询都不是生产可用方案。think-queue 结合 Redis 是 TP6 生态最成熟的选择。
- 任务类只认 fire() 方法：不是 handle()，也不是 run()。方法签名必须是 fire(Job $job, $data)，否则任务静默忽略
- 发布任务传类名字符串：正确写法是 Queue::push('app\job\CancelOrderJob', $data, 'order')；传对象或带 @ 符号的写法均无效
- 执行完必须手动 delete()：成功路径务必调用 $job->delete()，否则任务会被反复取出重试；失败时建议用 $job->fail() 或 $job->release(60) 延时重试
- queue 配置值即 Redis key 前缀：config/queue.php 中 'queue' => 'order' 会生成键名 queues:order，监听命令也必须匹配：php think queue:listen --queue order
延迟队列适合超时类场景（如订单取消）
Redis 有序集合（zset）天然适配延迟需求，比轮询更高效、更精准。
- 用时间戳作 score：将订单过期时间转为 timestamp，$redis->zAdd('order:delay:queue', $expireTs, $orderId)
- 消费进程需分布式锁：防止多实例重复处理同一订单，用 setNx + expire 实现，锁有效期建议设为 60 秒
- 幂等性校验不可少：消费前查 order:delay:processed:{$orderId} 是否已存在，存在则跳过
- 状态变更需事务兜底：更新订单状态与删除 zset 成员应放在同一事务中，避免中间状态不一致
定时 + 队列组合才是高可用标配
把耗时、易失败、需重试的逻辑从定时命令里剥离出来，只保留轻量触发动作。
- 定时命令只做两件事：查出待处理数据 ID 列表、批量推入队列。例如每天 2:00 执行 php think sync:order，内部只发 ID 到 Redis List，不执行同步逻辑
- 真正业务由常驻进程消费：用 supervisor 管理 php think queue:listen --queue order，保证进程崩溃后自动拉起
- 失败任务进 failed_jobs 表：think-queue 默认支持，便于人工干预或自动告警
- 不同业务走不同队列名：短信、邮件、订单同步各用独立队列（sms、email、order），避免互相阻塞
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
