要彻底禁用WordPress的wp-cron.php自动触发，必须在wp-config.php中添加define('DISABLE_WP_CRON', true);，此举从代码层切断所有HTTP请求触发源，使Cron完全停摆；仅删数据库wp_options表中的cron记录无效，因未设该常量时队列会自动重建。

WordPress数据库里怎么停用wp-cron.php自动触发

直接禁用，不是“屏蔽”或“跳过”，而是让wordpress彻底不尝试调用wp-cron.php——核心是改wp-config.php，不是动数据库。数据库本身不“运行”定时任务，它只存调度记录（wp_options表里的cron字段）。想让cron停摆，第一步必须在代码层切断触发源头。

• 在wp-config.php的define('DB_NAME', ...);之前，加一行：define('DISABLE_WP_CRON', true);
• 这行生效后，所有前台/后台页面加载都不会再GET请求wp-cron.php，从根上消除并发请求和超时风险
• 注意：仅设这个常量不会删掉已存在的调度记录，只是让它们“冻结”——不再被执行，也不再新增

数据库里删cron记录前先确认是否真要清空

删wp_options表里的cron值，等于清空整个WP Cron队列。但很多插件（比如备份、缓存预热、邮件重试）依赖这些记录，误删可能导致任务永久丢失、状态错乱。

• 先查当前内容：SELECT option_value FROM wp_options WHERE option_name = 'cron';（注意表前缀可能不是wp_）
• 如果返回的是空字符串或a:0:{}，说明队列本来就是空的，不用动
• 如果返回一长串序列化数据，建议先导出备份再操作：mysqldump -u user -p dbname wp_options --where="option_name='cron'" > cron-backup.sql
• 真正要删，用：DELETE FROM wp_options WHERE option_name = 'cron';，不是UPDATE，避免序列化损坏

为什么不能只靠数据库操作来“关闭”Cron

因为WP Cron本质是伪定时任务：它靠HTTP请求触发，不是系统级crond。数据库里删了cron记录，下次某个页面被访问时，WordPress发现队列空了，又会自动重建默认任务（比如wp_update_plugins），除非DISABLE_WP_CRON已启用。

WordPress API Pro

生产级WordPress REST API集成，用于管理文章、页面、媒体、WooCommerce产品、Elementor内容、SEO元数据、ACF及JetEngine字段

下载

• 没关常量就删库，等于“扫完地又开窗扬灰”——几小时内队列就恢复
• 某些主题或插件会在激活时主动写入新任务，删库后它们照常注册
• 更隐蔽的问题：部分插件检查cron选项是否存在，而非是否为空，删掉后可能报错或降级行为

替代方案：用系统crontab接管并精准控制

关掉WP自带Cron后，得用Linux crontab手动调用，否则像更新检查、订阅发送这类任务就真停了。这不是可选项，是必填项。

• 推荐最小粒度命令：curl -s https://yoursite.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1（注意URL必须带协议和域名）
• 加到crontab里，例如每15分钟跑一次：*/15 * * * * curl -s https://yoursite.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
• 不要用wget --spider或lynx，部分主机禁用，且curl对查询参数支持最稳
• 如果网站启用了基本认证或WAF拦截，需在curl里加-u user:pass或--header "X-Forwarded-For: 127.0.0.1"

真正麻烦的从来不是删那条数据库记录，而是删完之后谁来保证wp_scheduled_delete这种清理任务还能跑——它不跑，wp_posts里的revision和auto-draft只会越积越多。