FrankenPHP的worker模式下wp-cron默认不触发，因其常驻内存且无HTTP请求入口；必须禁用内置cron并改用系统crontab调用wp-cli执行任务。
FrankenPHP 默认不触发 wp-cron，因为没 HTTP 请求入口
FrankenPHP 的 worker 模式是常驻内存的，不依赖传统页面请求触发机制。而 wp-cron.php 默认靠外部 HTTP 请求（比如浏览器访问或系统 cron 调用 wget）来驱动执行。但在 FrankenPHP 的纯 CLI worker 场景下，wp-cron.php 文件根本不会被当作 Web 资源暴露或响应——它压根不走 HTTP 流程，所以靠“访问 URL”触发 wp-cron.php 会直接 404 或超时。
必须用 wp-cli + 系统 cron 替代默认触发链
可靠方案只有一条路：禁用 WordPress 内置触发，改用系统级 cron 定期调用 wp-cli 执行任务。这绕过了所有 Web 层依赖，也适配 FrankenPHP 的无 Nginx/FPM 架构。
- 在
wp-config.php中添加：define('DISABLE_WP_CRON', true); - 用
crontab -e添加真实系统定时任务，例如每 15 分钟执行一次：*/15 * * * * cd /var/www/your-site && /usr/local/bin/wp cron event run --due-now --path=/var/www/your-site/ > /dev/null 2>&1
-
--path参数必须显式指定，FrankenPHP 下wp-cli往往无法自动识别 WordPress 根目录 - 确保
wp-cli使用的 PHP 可执行文件与 FrankenPHP 加载的版本一致（比如都是 PHP 8.3），否则可能出现扩展缺失或配置不一致
自定义 cron 间隔在 FrankenPHP 下要小心注册时机
FrankenPHP 的 worker 进程长期存活，如果在主题 functions.php 或插件中直接用 add_filter('cron_schedules', ...) 注册新间隔，该代码只在首次加载时运行一次；但后续 worker 复用时不会重复执行这个 filter，导致新间隔对 cron 调度器不可见。
- 把自定义间隔注册逻辑移到
wp-config.php开头，或封装为 mu-plugin（必须放在wp-content/mu-plugins/下） - 避免在钩子如
init或wp中注册间隔——这些钩子在 worker 模式下可能根本不触发 - 验证是否生效：运行
wp cron schedule list，确认你的自定义间隔（如five_seconds）出现在输出中
手动调试时别信 wp-cron.php?doing_wp_cron 这套 URL
FrankenPHP 的 HTTP server 模块默认不启用 wp-cron.php 的可访问性，即使你强行配置路由让它能被访问，也会因缺少 $_SERVER['HTTP_HOST']、$_SERVER['REQUEST_URI'] 等关键变量而中途报错退出，日志里常见 PHP Warning: Undefined array key "HTTP_HOST"。
立即学习“PHP免费学习笔记（深入）”；
- 调试唯一可信路径是
wp cron event run --due-now或wp cron event run <hook_name></hook_name> - 加
--debug查看完整执行栈，比如：wp cron event run hits_set_zero --debug - 如果函数内用了
wp_mail()等依赖全局环境的函数，需确认wp-config.php已加载且ABSPATH正确定义
FrankenPHP 下 wp-cron 最容易被忽略的点，是误以为“常驻进程 = 自动轮询”，其实它完全不感知 WordPress 的调度器——cron 事件仍是被动触发的，只是触发器必须从 HTTP 切换到 CLI。任何试图复用旧有 wget 或 curl 方案的尝试，都会卡在第一层网络请求上。
