定时任务在crontab中静默失败主因是环境配置错误：未cd到项目目录、PHP路径不绝对、stderr未重定向、CLI内存限制低；ThinkPHP命令不支持$tries，需改用队列处理耗时/外部依赖任务，并通过Redis分布式锁+token校验防重复执行。
定时任务在 crontab 里静默失败，90% 不是代码问题
绝大多数 PHP 定时任务“没跑”或“跑一半就停”，根本原因不在业务逻辑，而在运行环境。crontab 默认以 root 身份、在系统根目录（/）下执行，而 php think app:sync-data 这类命令依赖项目根目录下的 vendor/autoload.php 和 config/。路径错、autoload 找不到、配置加载失败——脚本直接 fatal error 退出，连日志都写不进 runtime/log/（因为该目录可能不可写）。
- 务必在 crontab 条目中显式
cd /path/to/your/project &&切换工作目录 - 用绝对路径调用 PHP：
/usr/bin/php，避免依赖 shell PATH - 重定向 stderr 到日志：
2>> /path/to/project/runtime/cron-error.log，否则错误完全不可见 - 检查
php -i | grep 'memory_limit'，CLI 模式内存限制常低于 Web 模式，大数据任务易触发Allowed memory size exhausted
ThinkPHP 8 的 command 类不支持 $tries，别往里写
看到 Laravel 的 $tries = 3 就想照搬？别试。think command 是一次性 CLI 进程，没有队列 worker 那套生命周期管理。框架不会捕获异常、不会自动重入队列、更不会记录到 failed_jobs 表——它压根不碰这个表。
-
execute()方法里抛出未捕获异常 → 进程 exit(1) → cron 认为失败，仅此而已 - 强行在
execute()里写for ($i = 0; $i 是唯一可控方式 - 但要注意：数据库连接断开（
SQLSTATE[HY000]: General error: 2006 MySQL server has gone away）这类错误，break_reconnect => true对连接建立阶段无效，需在重试前手动Db::connect()->close()
真正需要重试的任务，应该进队列，而不是塞 cron
如果任务本身具备以下任一特征：耗时超过 30 秒、依赖外部 HTTP/API、涉及多步数据库操作、失败后需人工干预——那它就不该由 crontab 直接驱动。cron 只适合秒级/分钟级的轻量哨兵任务（如“检查队列是否卡住”）。
- 改用
Queue::later(60, new SyncDataJob())投递，把重试逻辑交给php artisan queue:work或php think queue:listen - 在 job 的
handle()中用$this->retryUntil(now()->addSeconds(30))控制总超时，比固定次数更合理 - 遇到
ConnectionException等瞬态错误，用dispatch($this)->delay(now()->addSeconds(2))实现退避重试；遇到InvalidArgumentException等业务错误，直接Log::error(...)并 return，不重试 - 确保
config/queue.php中 Redis 连接的'retry_after' => 60设置合理，否则任务可能被重复消费
Redis 分布式锁失效，是集群环境下最隐蔽的单点故障
多个调度器实例同时读取 MySQL 任务表并推送到 Redis 队列时，若只靠 SETNX 加锁却忽略锁值校验和过期时间，极易出现“锁被 A 拿走，A 挂了，B 误删锁，C 和 B 同时投递同一任务”的情况。
立即学习“PHP免费学习笔记（深入）”；
- 加锁必须带唯一 token：
Redis::set('scheduler:lock', $token, ['nx', 'ex' => 30]) - 释放锁前必须校验 token：
if (Redis::get('scheduler:lock') === $token) { Redis::del('scheduler:lock'); } - 不要用
DEL直接删键——这是原子性漏洞的根源 - 调度器自身也应有心跳机制，例如每 10 秒更新一次
last_heartbeat字段，主备切换时以此判断存活状态
