wp cron event list --fields=hook,next_run_relative --format=table wp option get cron --format=json | jq 'keys | length'
九点该发的文章九点十四才上线，日志里 publish_future_post 排在两千多条 wp_version_check 后面。站点访问量不大，任务却越积越多。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，默认的 WP-Cron 靠页面请求触发，一次只跑到时间预算用完就停，剩下的留到下次。没人访问就没有下次，任务全堆在 wp_options 的 cron 数组里。
这次卡住的地方就在「cron 数组积压」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。备份不是备了就行，恢复一次才算数，很多备份文件打开才发现是空的。
接口问题先分清是没发出去、发出去了没收到，还是收到了处理失败。
处理上按这个顺序：先列出到期时间已过的 hook，看看哪些是停用插件留下的；在 wp-config.php 里关掉内置 cron，改用系统 crontab 每五分钟跑一次；清掉废弃 hook 后手动触发一次，确认定时文章能准点进入 publish。
改完只确认一件事：cron 事件数量降到几十条，定时文章的上线时间和设定时间差在一分钟以内。