WordPress定时发布失败怎么办？从Missed Schedule到WP-Cron逐项恢复

WordPress定时文章到了时间却没有发布，通常不是编辑器没有保存，而是负责执行计划事件的WP-Cron没有在到期后获得正常运行机会。先确认服务器时间、站点时区和文章计划时间，再检查到期事件、回环请求与系统Cron，能比反复改发布时间更快找到根因。

先判断是单篇文章异常，还是整个任务队列停了

如果只有一篇文章没有发布，先检查它是否仍为“定时”状态、计划时间是否写错，以及保存后是否又被插件改动。若备份、邮件、缓存清理和插件任务也同时延迟，问题更可能位于WP-Cron触发链，而不是文章本身。

WordPress官方开发文档说明，WP-Cron不是持续运行的系统调度器。它会在页面加载时检查到期任务，因此低访问站点可能晚于计划时间执行；如果回环请求失败、WP-Cron被禁用却没有系统任务接管，延迟会持续存在。

第一步：把三个时间放到同一张表里

需要同时核对服务器当前时间、WordPress站点时区和文章保存的计划时间。不要看到小时数不一致就立刻改系统时区，WordPress会同时保存本地时间与GMT时间，盲目来回调整可能让后续文章再次偏移。

date
timedatectl status
wp option get timezone_string
wp option get gmt_offset
wp post list --post_status=future --fields=ID,post_title,post_date,post_date_gmt

timezone_string为空并不一定是故障，站点也可能使用GMT偏移值。关键是前台计划时间、后台显示时间和命令输出能否解释同一个时刻。若服务器时间明显漂移，应先修复NTP同步，再重新检查任务。

第二步：查看到期事件有没有积压

在站点目录、正确的PHP环境和站点运行用户下执行WP-CLI。先列出事件，不要一上来删除所有Cron记录。

wp cron test
wp cron event list --fields=hook,next_run_gmt,next_run_relative,recurrence
wp cron event list --due-now

wp cron test可帮助判断WordPress能否生成Cron请求；到期事件列表则用于确认队列是否真的积压。若列表中有大量重复Hook，应记录Hook名称、来源插件和最早到期时间。订单、邮件、备份类任务不能随意清空，否则可能造成业务数据遗漏。

第三步：恢复到期任务，但保留故障证据

重要文章可以先人工复核内容后发布，避免继续错过时效；随后再处理调度问题。要让当前所有到期事件运行，可在确认备份、执行用户和站点路径后使用：

wp cron event run --due-now

运行前后都应保存命令输出、PHP错误日志和Web服务器日志。若命令卡住或报错，真正的根因可能是某个插件任务超时、数据库锁等待、外部接口阻塞或PHP内存不足，而不是WP-Cron机制本身。

第四步：检查WP-Cron是否被禁用却无人接管

grep -n "DISABLE_WP_CRON" wp-config.php

如果配置中存在define('DISABLE_WP_CRON', true);，页面访问将不再触发WP-Cron。这个设置只有在系统Cron、主机面板计划任务或其他可靠调度器已经接管时才完整。检查系统任务是否存在、运行用户是否正确、命令路径是否仍有效，以及最近执行是否有错误输出。

不要同时保留多个高频触发器。页面触发、系统Cron和面板任务若重复执行，可能把“没有运行”变成“并发运行”，引发CPU峰值或重复任务。若问题表现为周期性高负载，可继续阅读WP-Cron导致CPU升高的排查方法。

第五步：排除回环请求、DNS和安全规则

WordPress可能通过本站地址发起回环请求。站点域名解析错误、HTTPS证书异常、基础认证、维护模式、防火墙或安全插件拦截，都可能让触发失败。应在服务器本机检查正式域名的DNS、TLS和响应状态，并对照站点健康报告与Web日志。

不要为了让Cron通过而永久关闭WAF或安全插件。更稳妥的做法是确认被拦截的请求特征，只为站点自身的合法回环设置最小范围规则，然后再次验证。

低访问站点怎样改用系统Cron

对发布时间要求较明确、访问量又不稳定的内容站，可以让系统Cron定期执行到期事件。下面只是路径示例，必须替换为当前站点目录和WP-CLI实际位置，并使用站点文件所属用户运行：

*/5 * * * * cd /var/www/example && /usr/local/bin/wp cron event run --due-now --quiet

确认系统任务能成功执行后，再禁用页面触发。五分钟不是所有站点的固定答案：新闻发布、商城队列和普通博客的时效要求不同，间隔应结合任务耗时和业务容忍度决定。

如果习惯通过可视化面板维护服务器计划任务，可查看极跃圈收录的宝塔面板信息页。面板只能帮助保存和查看任务，PHP版本、运行用户、站点路径和命令返回值仍需逐项核对。

恢复完成要看哪些信号

1. 到期事件列表不再持续堆积，失败Hook有明确处理结果。
2. 安排一篇短时间窗口的测试文章，实际发布时间与站点时区一致。
3. 系统Cron或页面触发只有一条清晰路径，不重复执行。
4. PHP、Web服务器和系统任务日志没有新的超时、权限或回环错误。
5. 备份、邮件等其他计划任务也恢复，而不只是文章状态被人工改成发布。

常见问题

出现Missed Schedule后文章会自动补发吗？

WP-Cron仍能被触发时，到期任务通常会在下一次运行机会进入队列；若触发链持续故障，就不能依赖自动补发。重要文章应先复核并处理，再修复Cron。

安装“定时发布修复”插件就够了吗？

插件可能增加补偿触发，但无法替代时区、回环请求、PHP错误和系统任务检查。先找到断点，否则插件只会遮住症状或增加重复任务。

可以直接把DISABLE_WP_CRON设为true吗？

只有系统Cron或其他调度器已经验证可用时才可以。先禁用页面触发而没有接管任务，会让定时发布、更新检查和插件队列一起停止。

系统Cron应该每分钟运行一次吗？

不一定。间隔要大于正常任务开销，并符合业务时效。普通内容站常从数分钟级开始观察，任务重、执行慢时还要防止上一轮未结束就启动下一轮。