定时任务负责“什么时候执行”，队列负责“怎么可靠地执行”；TP8需用crontab调用think命令触发定时逻辑，队列推荐Redis+think-queue实现异步、重试与并发控制。
新手搭建ThinkPHP项目时，定时任务和队列处理是两个高频需求，但容易混淆用途、配置错位或线上静默失败。核心原则是：**定时任务负责“什么时候执行”，队列负责“怎么可靠地执行”——二者可独立使用，也可组合（如定时触发队列消费）**。
定时任务：用 crontab 调用 think 命令最稳
ThinkPHP本身不带守护进程调度器，必须依赖系统级 crontab 触发命令行脚本。新手最容易卡在“本地能跑，crontab 不执行”。关键不是TP代码问题，而是环境没对齐：
- 绝对路径不能省：crontab 不读你的 .zshrc 或 .bashrc，PATH 极窄。必须写全 PHP 路径（which php 查）、项目根目录（cd /var/www/myapp）、think 入口（/usr/bin/php think sync:order）
- 工作目录必须切换：think 命令依赖自动加载和 config 文件，若不在项目根目录运行，会报 Class not found 或配置加载失败
- 日志输出要重定向：加 >> /tmp/cron-sync.log 2>&1，否则失败无声无息；建议用 trace() 写入 runtime/log/cron/ 下专用文件，比 echo 更可靠
- 测试先用分钟级表达式：比如 * * * * *（每分钟一次），等1分钟看日志是否生成，确认链路通了再调成真实周期
队列处理：别用 sleep 循环，优先选 Redis + think-queue
ThinkPHP 官方未内置队列服务，但社区成熟方案是 topthink/think-queue（适配 TP6/8）。它不是“替代定时任务”，而是解决“异步、重试、并发控制”问题。例如：用户下单后发短信，不能阻塞响应，就该丢进队列。
- 不要手写 while(true) + sleep：这种伪常驻进程极易僵死、无法平滑重启、不支持多实例，生产环境严禁使用
- 推荐驱动：Redis：轻量、高性能、自带原子性，比数据库表队列更合适中小项目；安装 predis/predis 扩展后，在 config/queue.php 中设 'default' => 'redis'
- 消费者启动命令：用 php think queue:listen --daemon 启动常驻进程；配合 supervisor 管理进程生命周期，避免意外退出
- 任务类需继承 Job 类：实现 fire() 方法，内部可安全调用模型、Db、Cache；失败自动重试（默认3次），超限进 failed_jobs 表
定时 + 队列组合：典型场景示例
很多新手以为“定时任务里直接处理业务”就够了，但遇到耗时操作（如导出万条Excel、调第三方API）就会超时或阻塞后续任务。正确做法是：定时任务只做“触发”，把重活交给队列。
立即学习“PHP免费学习笔记（深入）”；
- 每天凌晨同步订单：crontab 每天 2:00 调 php think sync:order，该命令只做两件事——查出待同步ID列表、批量推入 Redis 队列；真正同步逻辑由 queue:listen 进程异步消费
- 每5分钟检查设备心跳：crontab 每5分钟调 php think check:heartbeat，该命令只查出离线设备ID，发消息到队列；推送通知逻辑单独写 Job 类，支持失败重试和飞书/邮件多通道
- 注意权限与用户一致性：crontab 通常以 root 或 www-data 用户运行，确保该用户对 runtime/、queue 数据源（如Redis密码）、日志目录都有读写权限，否则队列无法写入或消费失败
调试与排障：三步定位问题根源
任务没执行？别猜。按顺序检查：
- 看 crontab 是否生效：执行 sudo systemctl status cron（Linux）确认服务运行；crontab -l 看规则是否存在；临时改用 * * * * * 测试
- 看命令执行日志：检查重定向的日志文件（如 /tmp/cron.log），是否有 “command not found”、“No such file or directory”、“Class 'xxx' not found” 等明确报错
- 看 ThinkPHP 日志：打开 runtime/log/cron/ 或 runtime/log/queue/ 下对应日期的文件，搜索 ERROR 或 Exception，结合 trace() 输出定位具体哪一行出错
