有一次促销价格没有按时生效，我先看了 cron_schedule，发现不是某一个任务失败，而是一大片记录都变成了 missed。这种情况如果直接清表，页面会暂时清爽，但真正的问题一分钟后还会回来。

先判断是 cron 根本没跑，还是来不及跑

先把最近半小时的状态按时间排出来：

SELECT job_code, status, scheduled_at, executed_at, finished_at, messages
FROM cron_schedule
WHERE scheduled_at > NOW() - INTERVAL 30 MINUTE
ORDER BY schedule_id DESC;

如果只有 pending 和 missed，完全没有新的 running、success，先查操作系统计划任务。Web 站点能打开，不代表 CLI 使用的是同一个 PHP：

crontab -l
which php
php -v
php bin/magento cron:run

手工执行时要使用和系统 cron 相同的用户、工作目录及 PHP 路径。常见现场是 crontab 仍指向已下线的 PHP，或者发布后目录改名，命令从一开始就没进入 Magento。

有 success 但 missed 仍增长，要找堵住队列的任务

Magento 会提前生成计划。任务超过 Schedule Lifetime 仍未执行才变成 missed。此时应比较 executed_at - scheduled_at，再找耗时异常的 job。第三方同步、报表导出和全量商品脚本尤其容易拖死默认 cron 组。

自定义任务应按主键游标或时间窗口拆批，不能每分钟从第一行重新扫全表。需要互斥时，锁必须在异常退出后可释放，否则后续任务会全部跳过。

恢复时别一股脑重跑所有 missed

订单邮件、库存同步可能有外部副作用。补跑前先确认幂等：重复执行会不会发两封邮件、扣两次库存或重复调用 ERP。索引任务可以定向重置；业务任务更适合按 job_code 和业务主键补偿。

连续观察两个调度周期，新任务能准时从 pending 到 running 再到 success，积压持续下降，才算恢复。清表只能处理症状，系统 cron、任务耗时和幂等才是根。