WordPress 定时任务与 WP-Cron：怎么禁用、接系统 cron，积压怎么排查（2026）
摘要：定时发布不按时、备份插件老跳、更新检查挤在一起，多半跟 WP-Cron 有关。官方文档写明：它只在有人访问页面时触发，不是系统 cron。本文按 WordPress 开发者手册整理：何时改成系统定时、DISABLE_WP_CRON 怎么写、crontab 怎么钩 wp-cron.php，以及用 WP-CLI 看积压。只放官网链接，不写单价。
依据：WordPress Plugin Handbook · Cron、Hooking WP-Cron Into the System Task Scheduler、Editing wp-config.php、wp cron event list。查询日期：2026-10-26（北京时间）。只放官网普通链接（
affiliate_later）。操作前先备份站点与数据库，见网站定期备份方案。
你设了「明天早上 9 点发文」，结果中午才出来；备份插件写着每小时跑，日志却空了半天。先别急着卸插件。WordPress 自带的调度叫 WP-Cron。它和 Linux 里一直在走的系统 cron 不一样：只有有人打开页面时，才会顺手检查一遍到期任务。访问少的站点会拖点；访问很密的站点又可能在每次请求里多打一轮调度。
本站已有用 Docker 部署 WordPress与网站可用性监控。本文只收窄到一件事：什么时候该关掉页面触发的 WP-Cron、怎么接到系统定时、积压时先看哪几条命令。
一、WP-Cron 实际在干什么
官方手册写明：核心功能（检查更新、定时发文等）和不少插件都走 WP-Cron；每次页面加载时，WordPress 会查看待执行任务队列，到期的就在这次请求里跑。
两头翻车都常见：
| 场景 | 你看到的现象 | 原因（官方口径） |
|---|---|---|
| 站点几乎没人访问 | 定时文、备份、清理任务「到点不跑」 | 没有 page load，队列不会被叫醒 |
| 站点流量很大 | TTFB 偶发变慢、PHP 工人被占满 | 每次请求都可能 spawn 一轮 cron |
| 任务挤在一起 | 一下子跑很多 hook | 错过的任务会进队列，下次有机会一起补跑 |
所以：低流量站更怕「漏跑」；高流量站更怕「每次访问都顺带调度」。两边都适合评估系统 cron + 禁用页面触发这一套。
二、正确顺序：先接系统定时，再禁用 WP-Cron
官方《Hooking WP-Cron Into the System Task Scheduler》写得很直：用系统任务调度按固定间隔请求 wp-cron.php，然后再在 wp-config.php 里关掉页面触发。顺序反了，备份、定时发布、邮件队列会在静默中停掉，往往没有大红报错。
1. 在服务器 crontab 里钩住站点
Linux / macOS 常见写法（把域名换成你的站点；官方示例用 wget --delete-after）：
*/15 * * * * wget --delete-after https://你的域名/wp-cron.php
核对要点：
- 间隔先按 15 分钟量级试（
*/15）；备份类任务本身另有自己的 schedule，这里只负责「叫醒」WordPress。 - 用 HTTPS 真域名，别写内网 IP 却忘了证书校验失败。
--delete-after：不把响应体存成文件；少了它，wget 可能在家目录堆垃圾文件。- 若主机禁止出站 wget，可改用
curl -fsS或 WP-CLI（见第四节），以你主机文档为准。
宝塔 / 面板用户：在「计划任务」里加「访问 URL」类任务，目标填 https://你的域名/wp-cron.php，频率与上表一致即可；改完再往下写常量。
2. 在 wp-config.php 禁用页面触发
官方要求在 wp-config.php 增加：
define( 'DISABLE_WP_CRON', true );
同页《Editing wp-config.php》还提到：
ALTERNATE_WP_CRON：用重定向方式跑 cron，依赖额外行为，官方也写有风险，不是本文推荐的主路径。WP_CRON_LOCK_TIMEOUT：限制同一时间锁间隔，排障时才动。
改完后做三步核对：前台打开首页；后台「已发布」里设一篇 10–20 分钟后的定时文（或看备份插件下次执行时间）；等过系统 cron 周期，看任务是否按点走。不要只写常量、不接系统定时。
三、积压怎么查：先列队，再决定清不清
装了 WP-CLI 时，官方命令 wp cron event list 会列出 hook、下次运行时间（GMT / 相对时间）、复发间隔。字段默认含 hook、next_run_gmt、next_run_relative、recurrence。
现场排查顺序：
- SSH 进站点目录，跑
wp cron event list（或加--fields=hook,next_run,recurrence）。 - 看有没有
next_run_relative已经是负数、或大量同名 hook 堆在一起。 - 手动补跑到期任务：
wp cron event run --due-now（以你环境 WP-CLI 版本帮助为准）。 - 注意：
wp cron test在已经DISABLE_WP_CRON=true时往往会报「禁用」类错误，这是预期；此时应核对系统 crontab 是否在打 wp-cron.php，而不是死磕 test 命令变绿。
没有 WP-CLI 时：看备份 / 缓存 / 邮件插件自己的「上次运行」日志；同时在服务器查 crontab 与面板计划任务是否仍在、URL 是否 200。
四、和建站其他件怎么配合
- 对象存储备份、数据库 dump：任务本身仍由插件或脚本注册到 WP-Cron；你换成系统 cron 后，它们只是被更准时地叫醒。备份策略见网站定期备份与对象存储整站备份演练。
- CDN / 全页缓存：极少数配置会把对
wp-cron.php的请求也缓存掉；计划任务 URL 应直达源站，必要时在 CDN 里对该路径绕过缓存。 - 安全组与 HTTPS：定时请求走 443；端口收敛见安全组最小开放。
- 搬家或换机：迁服后记得在新机器重写 crontab，旧机任务指向旧域名会悄悄失败，见WordPress 搬家到新服务器。
五、动手前核对清单
- □ 已备份文件与数据库。
- □ 已在系统 crontab / 面板加好对
https://域名/wp-cron.php的访问（先于禁用）。 - □
wp-config.php写入DISABLE_WP_CRON为 true，语法无多余引号。 - □ 用浏览器或
curl -I确认该 URL 返回成功（非整站缓存页）。 - □
wp cron event list（或插件日志）里下次运行时间在推进。 - □ 试一篇短时定时发布或观察备份插件「上次成功」时间。
- □ 改完后 24 小时内盯一次邮件发送、缓存预热、会员到期类任务是否仍在跑。
六、常见坑
- 只禁用、不接系统 cron：站点变「安静」后，定时文与备份一起停。
- crontab 写了 http 又强制跳 https：任务拿到 301/302 循环或证书错误，队列照样堆。
- 多站点 / 反代：请求必须落到正确的站点 URL（含
www与协议），否则 hook 挂在别的 blog_id 上。 - 把
ALTERNATE_WP_CRON当万能开关：官方已提示依赖非原生行为，优先用系统调度 +DISABLE_WP_CRON。 - 在生产直接
wp cron event delete清陌生 hook：先查是哪个插件注册的；乱删可能导致更新检查或会员权益任务消失。
官网入口（普通链接，无返利）：WordPress 开发者手册 · Cron、系统调度衔接、wp-config 说明、WP-CLI cron event list。
来源与查询日期
- developer.wordpress.org Plugin Handbook：Cron；Hooking WP-Cron Into the System Task Scheduler（页内含
DISABLE_WP_CRON与 wget 示例）。 - developer.wordpress.org Advanced Administration：Editing wp-config.php（
DISABLE_WP_CRON/ALTERNATE_WP_CRON/WP_CRON_LOCK_TIMEOUT）。 - WP-CLI 命令文档：wp cron event list。
- 查询日期：2026-10-26（北京时间）。主机面板文案以你当前控制台为准。
