WordPress 定时发布不准点或备份/邮件从不跑：先分清 WP-Cron 触发与 DISABLE_WP_CRON，再查回环与系统 Cron

预定今天 09:00 上线的文章，拖到中午还停在「定时」；备份插件说每晚跑，却从未生成包；事务邮件、会员到期提醒也像被忘了一样------后台 Site Health 还可能直接报 「计划事件未能运行 / 无法完成回环请求」 。这和今天已写过的「登录后跳回登录页（Cookie / CDN）」「Elementor 编辑器空白」「前台 502/503（PHP-FPM）」「白屏 / 严重错误（Fatal / 插件二分）」以及 Shopify 结账按钮灰色不是一类故障：那些卡在会话、编辑器资源、网关或 PHP 应用层；这里卡在 WP-Cron 的触发链路------没人访问就不跑、DISABLE_WP_CRON 后系统 Cron 没接上、站点回环被拦、单个 hook 回调崩了，或 WooCommerce Action Scheduler 积压把队堵住。

更稳的顺序是：先分清是 低流量未触发 / 禁用内置 Cron 却未接系统任务 / 回环失败 / 单事件回调异常 / Action Scheduler 积压 → 用 Site Health 看回环 → 查 wp-config.php 里的 DISABLE_WP_CRON → 用 WP Crontrol（或同类）看 overdue → 有 CLI 再 wp cron event list / wp cron test → 修回环（Basic Auth、防火墙、HTTPS、自解析）→ 用系统 Cron 每 5 分钟打 wp-cron.php 并正式关掉内置触发 → 最后用一篇短定时文验收。别一上来就重装备份插件，也别在未分清触发方式时反复点「立即发布」。

很多站在换主机、上 CDN、或给预发环境加了访问密码之后才「突然」出现这类现象：以前定时还能凑合准点，迁移后备份与邮件一起停。根因通常不在插件本身，而在 触发器与回环路径变了------内置 Cron 仍假定「随时有人访问 + 服务器能请求自己」，这两条任一不成立，表现就是不准点或从不跑。

先分清：未触发 / 已禁用未接管 / 回环失败 / 单 hook 崩 / 队列积压

「定时任务不准」常见落在五条线上，别和登录环、502、白屏混着改：

低流量未触发：默认 WP-Cron 靠前台/后台访问「顺便」触发。夜里没人打开站点，备份、邮件、定时发布就会拖到「下一次有人访问」才补跑，看起来像「不准点」。
DISABLE_WP_CRON 为 true，但系统 Cron 没接好 ：有人按主机文档关掉了内置 Cron，却忘了配 */5 * * * * 去请求 wp-cron.php，或路径/密钥写错------结果是彻底不跑。
回环失败（loopback）：Site Health 提示无法完成到自身的 HTTP 请求。常见于站点开了 HTTP Basic Auth、WAF/防火墙拦本机、HTTPS 证书自签导致校验失败、或服务器把域名解析到外网 IP 绕不回来。
单事件回调崩了：队列里该 hook 一直 overdue，执行时报 PHP Fatal / 超时，后续同类任务跟着拖；其它无关 hook 可能仍正常。
WooCommerce Action Scheduler 积压（次要）：商店邮件、订阅、库存同步走独立队列表。WP-Cron 能触发，但 AS 表积压、runner 卡死时，表现仍是「邮件/任务从不跑」------先确认 WP-Cron 本身健康，再查 AS pending/failed。

另记易混项：「立即运行」手动能成功，但定时仍晚 ，多半是触发频率或系统 Cron 间隔问题；手点也失败，优先回环与回调 Fatal。

第一步：Site Health ------ 先看回环与计划事件

用管理员打开 工具 → 站点健康 → 信息 / 状态：

看是否有「计划的事件未能运行」「无法完成回环请求」等红/橙项。
回环失败时，记下提示原文（Asia/Shanghai 时间戳一并记进运维备忘）。
预期定界 ：
- 回环失败 → 先修本机访问自身（见第四步），不要先改备份插件；
- 回环正常、但事件 overdue → 进第二步看是否禁用了内置 Cron；
- 仅个别 hook 失败 → 记 hook 名，进第三步 Crontrol / CLI。

这一步结束时应能口头说清：「是回环挂了，还是 Cron 根本没被触发。」

第二步：核对 DISABLE_WP_CRON ------ 禁用了就必须有人接管

打开站点根目录 wp-config.php（require 之前），搜索：

php 复制代码

define( 'DISABLE_WP_CRON', true );

未定义或为 false：内置「访问触发」仍开着；低流量站会「不准点」，高流量站通常够用，但高峰时偶发拥堵。
为 true ：内置触发已关，必须有系统 Cron / 主机面板「计划任务」周期性请求 https://你的域名/wp-cron.php（或 CLI wp cron event run --due-now）。没有接管 = 所有依赖 Cron 的功能停摆。
主机面板若已有「WordPress Cron」开关，确认与 wp-config 一致，避免「面板以为开了、文件里却禁用」的双源混乱。

主机迁移、换 CDN、上 Basic Auth 之后，回环与 Cron 触发最容易一起坏；把「触发方式、回环、系统任务」放在同一条链上排查，可参考主机与迁移侧的 WP-Cron / 回环排查，避免只重装邮件插件却不动触发层。

第三步：WP Crontrol / WP-CLI ------ 看 overdue 与单 hook

安装并启用 WP Crontrol（或主机提供的 Cron 查看器）：

打开 Cron Events，按 Next Run / overdue 排序；记下长期 overdue 的 hook（如 publish_future_post、备份插件 hook、邮件相关 hook）。
对单条点「Run now」：成功说明回调本身可用，问题在触发；失败则看 PHP 错误日志里该 hook 的 Fatal / timeout。
有 SSH / WP-CLI 时：
- wp cron event list --fields=hook,next,recurrence
- wp cron test（检测生成器与生成事件）
- wp cron event run --due-now（维护窗口补跑到期事件）
Woo 店若邮件仍不发：后台 WooCommerce → Status → Scheduled Actions，看 pending / failed 数量；积压明显时在 WP-Cron 健康后再清失败任务或提高 runner，勿与「整站 Cron 死了」混为一谈。

第四步：修回环 ------ Basic Auth、防火墙、HTTPS、自解析

Site Health 报回环失败时，按环境逐项收：

HTTP Basic Auth / 维护墙 ：应用层鉴权会拦 WordPress 访问自己。给 wp-cron.php 与内部回环路径放行，或在鉴权规则里排除 Cron；测完再收紧。
防火墙 / WAF / 安全插件：本机 IP、环回、或「服务器访问自身」被当成攻击。临时放行源站 IP，确认回环变绿后再收规则。
HTTPS / 证书：站点 URL 为 https，但证书自签、过期或中间证书不全，PHP 校验失败会导致回环挂。修好证书或在维护窗口临时放宽校验，确认问题出在证书校验而非 DNS。
DNS 自解析：服务器解析域名走到公网 VIP，又被防火墙挡回。在 hosts 或内网 DNS 把域名指到本机/内网地址，再测 Site Health。
预期：Site Health 回环项变绿；再跑一次 overdue 的 publish_future_post 或备份 hook。

第五步：系统 Cron 接管 ------ 每 5 分钟打 wp-cron.php

流量低或不想依赖「有人访问」时，推荐固定模式：

在 wp-config.php 写入：define( 'DISABLE_WP_CRON', true );
系统 crontab（或主机「计划任务」）增加类似：

bash 复制代码

*/5 * * * * curl -sS -o /dev/null https://你的域名/wp-cron.php?doing_wp_cron >/dev/null 2>&1

（也可用 wget -q -O -；部分主机要求带密钥参数，按文档拼接。）

确认任务用户有网络权限、URL 与正式站点一致（含 www / HTTPS）；预发与生产域名不要混用同一条 crontab。
若主机只允许「访问 PHP 文件」类任务，指向站点根下的 wp-cron.php 即可，勿指向后台漂亮的固定链接管理页。
等两个 5 分钟周期后，再看 Crontrol 是否还大面积 overdue；系统日志里应能看到对应时间的 curl/wget 成功记录。

常见误操作（尽量避开）

只重装邮件 / 备份插件，不查 DISABLE_WP_CRON 与回环------装完依旧不跑。
同时打开内置 Cron 又加系统 Cron，且间隔极短：可能造成重复执行；接管时请显式 DISABLE_WP_CRON true。
在未备份 crontab / wp-config 的情况下批量改触发方式，出问题无法单条回滚。
把 Action Scheduler 积压当成「WP-Cron 全死」：先证明核心 publish_future_post 能准点，再清 Woo 队列。

第六步：验收清单（无软广，只验结果）

同一维护窗口建议勾完下面几项再收工：

Site Health：回环请求成功；无「计划事件未能运行」红项（或仅剩已知、已记录的第三方 hook）。
DISABLE_WP_CRON 与系统 Cron：要么内置触发且流量足够，要么禁用 + 每 5 分钟系统任务，二者必居其一且一致。
WP Crontrol：核心 hook（含 publish_future_post）不再长期 overdue；手跑嫌疑 hook 无 Fatal。
发一篇 5～10 分钟后定时发布 的短文：到点应自动变已发布（无痕前台可打开）。
备份 / 邮件：看下一轮计划是否生成新备份包或发出测试事务邮；Woo 店再扫一眼 Action Scheduler pending 是否在下降。
变更可回滚：记下改过的 wp-config、crontab 行、防火墙放行项，出问题能单条撤回。

把「触发 → 回环 → 系统 Cron → 单 hook →（可选）Action Scheduler」按顺序走完，大多数「定时不准点 / 备份从不跑 / 邮件像消失」会落在前四步之内。与登录 Cookie、Elementor 资源、502、Fatal 白屏分界清楚，就不必在错误层反复重装插件。