wp-cron 拖慢网站？改用系统 cron 定时任务解决

引言

WordPress 里发布定时文章、检查插件更新、清理过期数据、发送邮件，靠的都是定时任务。很多人不知道，WordPress 的定时任务默认用的是「伪 cron」：它不依赖服务器定时器，而是在每次有人访问网站时，由 wp-cron.php 顺带检查有没有到期的任务。听起来很聪明，问题也正出在这里。每个页面请求都可能触发一次 cron 检查，一旦有耗时任务（比如备份、批量发信、抓取远程数据），就会让这次访问变得很慢，访客明明只是点开一篇文章，却要等好几秒。更糟的是，低流量站点可能长时间没人访问，任务迟迟不触发，导致定时发布的内容延迟上线。解决办法很直接：关掉 WordPress 的伪 cron，改用服务器系统的定时任务来触发。

故障原因分析

1. 每次访问都触发 cron 检查。WordPress 在页面加载初期调用 spawn_cron()，如果任务到期就发起一个内部请求去执行 wp-cron.php，这个请求会占用 PHP 进程和数据库连接。

1. 耗时任务拖累访客。备份、邮件群发、图片压缩、远程 API 拉取等任务被塞进 cron，正好赶在访客访问时执行，直接把这次请求拖慢。

1. 并发请求叠加。高并发时每个请求都尝试触发 cron，可能同时拉起多个 wp-cron.php，CPU 飙升，站点雪崩。

1. 低流量站点任务不触发。没有访客就没有伪 cron 调用，定时发布失效、备份不执行，等到你发现时已经误事。

1. 插件滥用 cron。部分插件每分钟甚至每次请求都注册定时任务，wp_options 里的 cron 选项被反复读写，进一步加重负担。

分步解决方案

第一步：禁用 WordPress 伪 cron

在 wp-config.php 里加一行常量，关掉每次访问触发的伪 cron：

// wp-config.php
define( 'DISABLE_WP_CRON', true );

加完之后，WordPress 就不再在访客访问时触发定时任务，站点响应会立刻变稳。但注意：此时必须手动配置系统定时任务来接替，否则所有定时功能都会停摆。

第二步：配置系统 crontab 触发 wp-cron

登录服务器，编辑当前用户的 crontab（宝塔面板用户可在「计划任务 → Shell 脚本」里图形化添加）：

# 编辑 crontab
crontab -e

加入一行，让它每 5 分钟访问一次 wp-cron.php：

# 每 5 分钟触发一次 wp-cron，路径按实际替换
*/5 * * * * curl -s https://www.example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

如果服务器无法用 curl 访问自己的公网域名（有些机房回环不通），可以改用 wget 或直接调用 PHP CLI：

# 方式二：用 wget
*/5 * * * * wget -q -O - https://www.example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

# 方式三：用 PHP CLI 直接运行（无需经过 HTTP）
*/5 * * * * /www/server/php/80/bin/php /www/wwwroot/example.com/wp-cron.php >/dev/null 2>&1

推荐第一种。?doing_wp_cron 参数会告诉 WordPress 这是 cron 触发请求，避免被伪 cron 逻辑重复处理。

第三步：检查任务是否按预期运行

先把 wp-cron.php 手动在浏览器打开一次，确认能正常返回（一般返回空白）。再去「工具 → 站点健康 → 信息 → 计划任务」或装 WP Crontrol 插件，看任务列表里各任务的「下次运行时间」是否在正常滚动。也可以临时在任务里加个写日志动作观察。

用 WP Crontrol 还能直观地看到有哪些定时任务、由哪个插件注册、执行频率多高，方便揪出滥用 cron 的插件（比如每 60 秒跑一次的任务）。

第四步：清理无用和过密的定时任务

对每个请求都注册、或频率过高的任务要留个心眼。在 WP Crontrol 里可以删除废弃任务；对确需保留但频率过高的，评估能否降低频率。插件卸载后遗留的 cron 事件也应一并清掉，它们会一直空跑并占用调度。

第五步：区分环境选择触发频率

低流量小站每 5 分钟触发一次足够；发布时效要求高的站点可以调到 1 分钟。触发频率别太高，每次触发都会起一个 PHP 进程，1 分钟一次已能满足绝大多数需求。如果主机有资源限制，改用 PHP CLI 方式能省去 HTTP 开销。

第六步：验证站点响应是否变好

禁用伪 cron 后，用 Query Monitor 或 F12 看 wp-cron.php 是否还出现在页面请求里，正常情况下应该消失。再用测速工具对比前后 TTFB，尤其注意那种「偶发性卡顿」是否消失——它往往就是访客撞上了 cron 任务。

常见踩坑点

1. 只禁用不配置系统 cron。加完 DISABLE_WP_CRON 就撒手，结果定时发布全失效，等到内容没按时上线才发现，务必同时配好 crontab。

1. 触发 URL 写成本地路径导致失败。有些服务器不能用 127.0.0.1 或本机 IP 访问自己，用真实域名最稳。

1. cron 任务里执行超时脚本。如果 wp-cron.php 跑的任务超时，系统 cron 也会卡住，建议给 curl 加 --max-time 60 限制，避免进程堆积。

1. 多个来源同时触发。既留了伪 cron 又配了系统 cron，任务会重复执行，务必确认 DISABLE_WP_CRON 已生效。

1. 忘了 ?doing_wp_cron 参数。不加这个参数虽然通常也能跑，但可能触发额外的重复判断，建议带上。

总结

wp-cron 拖慢网站的根源，是它把定时任务的检查挂在了访客的每一次访问上，任务一重就拖累响应，站点一闲又不触发。正解是用一行常量 DISABLE_WP_CRON 关掉这套伪 cron，再交给服务器系统定时任务每 5 分钟触发一次 wp-cron.php（或直接用 PHP CLI 运行）。配合 WP Crontrol 梳理任务列表，清掉废弃和过密的调度，定时发布、备份、清理就都能在不打扰访客的前提下稳定运转。这是个改动小、收益稳的优化点，尤其适合访问量不高但定时功能频繁的独立站。