WordPress定时任务WP‑Cron踩坑

WordPress 的 WP-Cron 并不是真正意义上的系统定时任务，它只有用户访问网站时才会被触发。
一旦网站访问量低、页面有缓存，或者访问请求被拦截，post_scheduled 这类任务就会延迟甚至完全不执行。
解决思路很直接：禁用内置的 WP-Cron，改用服务器系统 crontab 按固定时间调用。 本文适合零基础用户，照着操作就能把 WordPress 定时任务迁移到系统层面，让任务按计划准确执行。

动手前先确认三件事

在改配置之前，先确认你的服务器环境支持以下条件：

• 你拥有服务器 SSH 登录权限，或者宝塔面板等可以管理 crontab 的工具。
• 可以修改 WordPress 根目录下的 wp-config.php 文件，至少要有文件编辑权限。
• 确定 PHP 已加入系统环境变量。如果不确定，登录 SSH 后执行 which php，有路径返回就说明可以直接用；没有返回就需要用绝对路径，例如 /usr/bin/php 或 /www/server/php/83/bin/php。

另外还要确认 WordPress 站点路径。
假设你的站点目录是 /www/wwwroot/example.com，后续命令里记得替换成你自己的路径。

第一步：在 wp-config.php 里禁用 WP-Cron

用文本编辑器打开站点根目录下的 wp-config.php，在 /* 好了！
请不要再继续编辑。
请保存本文件。
*/ 这一行之前添加：

define('DISABLE_WP_CRON', true);

注意：这行代码必须放在 require_once ABSPATH . 'wp-settings.php'; 之前，否则不生效。
保存后，WordPress 内置的伪定时任务就会被关闭。

第二步：添加系统 crontab 定时规则

登录 SSH，执行 crontab -e 进入当前用户的定时任务编辑界面。
第一次使用会提示选择编辑器，一般选 2 或 nano 即可。

在文件末尾添加一行：

*/5 * * * * /usr/bin/php /www/wwwroot/example.com/wp-cron.php > /dev/null 2>&1

这条规则的意思是每 5 分钟执行一次 WordPress 根目录下的 wp-cron.php，并丢弃输出。
如果你刚才通过 which php 得到的路径不是 /usr/bin/php，请替换为实际路径。

如果你的服务器禁用了 PHP 命令行执行，也可以用 Web 方式调用：

*/5 * * * * wget -q -O - http://你的域名/wp-cron.php?doing_wp_cron > /dev/null 2>&1

两种方式选一种即可，不必重复添加。

第三步：用 WP-CLI 更优雅地执行任务（可选）

如果安装了 WP-CLI，可以在 crontab 里直接调用 WordPress 的定时任务队列：

*/5 * * * * /usr/local/bin/wp cron event run --due-now --path=/www/wwwroot/example.com >> /var/log/wp-cron.log 2>&1

这种方式只处理到期的任务，比直接执行 wp-cron.php 更省资源，而且日志记录更清楚。
前提是你的服务器已经安装 WP-CLI，且路径与上面的示例一致。

这些坑一定要避开

• DISABLE_WP_CRON 位置放错：放在 wp-settings.php 引入之后就不会生效，只要写错位置，系统 crontab 和内置 WP-Cron 会同时运行，任务可能被重复执行。
• crontab 里的 PHP 路径写错：很多服务器有多版本 PHP，路径写错会出现 command not found。先执行 which php 再复制到规则里。
• 站点路径带空格或特殊字符：如果路径里有空格，需要用引号把路径包起来，或者改用 Web 方式调用。
• 启用了网站缓存或 CDN：如果用 Web 方式调用 wp-cron.php，CDN 或安全防护可能拦截该请求。推荐优先使用 PHP CLI 方式，不要依赖 HTTP 访问。
• 服务器时区与站点时区不一致：crontab 使用系统时区，而 WordPress 后台任务基于站点时区。如果两者相差几个小时，任务看似不按时执行。建议在服务器和 WordPress 里都设置为同一时区。

如何确认任务真的在跑

改完后先别急着关页面，做下面两步验证：

1. 在 crontab 规则中临时去掉 > /dev/null 2>&1，改成 >> /tmp/wp-cron.log 2>&1，等 5 分钟后查看这个日志文件，里面有输出说明 PHP 被正常调起。
2. 在 WordPress 后台安装一个类似 WP Crontrol 的插件，打开“工具 → Cron Events”，如果页面显示任务列表并且时间和当前时间接近，说明新的系统 cron 已经在驱动任务执行。

如果你之前遇到过“计划任务被卡住”“定时发布文章失败”“更新缓存不及时”这类问题，完成迁移后通常会明显改善。
需要留意的是，具体的 crontab 执行频率可以根据任务重要程度调整，比如发邮件任务每 1 分钟一次，备份任务可以每 10 分钟或更久一次。
配置完以后不要忘记在服务器上检查 cron 服务是否开启，执行 systemctl status crond（CentOS）或 systemctl status cron（Ubuntu）即可看到运行状态。