WordPress 与 FrankenPHP Worker 模式不兼容，因其单次执行模型与 Worker 要求的长期驻留、手动轮询请求及状态重置机制存在根本冲突；官方明确不支持，正确做法是使用 FrankenPHP 的普通 FastCGI 模式。
WordPress 的入口机制和 FrankenPHP Worker 模式不兼容
FrankenPHP 的 worker 模式要求 PHP 脚本**长期驻留、主动轮询请求、手动调用 frankenphp_handle_request()**，而 WordPress 是典型的单次执行模型：index.php 加载配置、初始化主题/插件、渲染页面、输出 HTML、退出。它没有循环逻辑，也不感知“下一次请求”，更不会调用 frankenphp_handle_request() —— 这是根本性冲突。
你强行在 index.php 末尾加个 while (true) { frankenphp_handle_request(); }，结果只会是：第一次请求能出内容，之后所有请求卡死或返回空白，因为 WordPress 的全局状态（如 $wp_query、$wp_rewrite、已加载的插件钩子）没做重置，第二次请求进来时会复用脏状态，直接崩溃或错乱。
WordPress 插件和主题大量依赖 request 生命周期钩子
WordPress 的运行高度依赖 init、wp、template_redirect 等 hook，这些钩子默认在每次请求开始时由 wp-settings.php 触发。Worker 模式下，PHP 进程不重启，这些 hook 只会执行一次 —— 后续请求完全绕过初始化流程，导致：
-
is_admin()、is_singular()等条件函数失效（内部状态未更新） - 插件注册的
add_action('wp_enqueue_scripts', ...)只生效一次，静态资源不加载 - 缓存插件（如 WP Super Cache）的请求上下文丢失，生成错误缓存或拒绝服务
- 多站点（Multisite）切换失败，
switch_to_blog()失效
FrankenPHP 官方明确不支持 WordPress 的 Worker 模式
这不是配置问题，而是架构层面的否定。FrankenPHP 文档和源码注释里反复强调：worker 模式适用于“可自行管理生命周期”的应用，例如 Laravel Octane、Symfony Runtime 或自研 CLI 风格服务。WordPress 不在此列。
立即学习“PHP免费学习笔记（深入）”；
使用tbot机器ID身份文件配合tsh CLI，通过Teleport访问控制SSH登录托管主机或执行远程命令。
你能在 Caddyfile 里写 worker { file index.php }，FrankenPHP 也不会报错 —— 它会尝试启动，但很快因致命错误退出（日志里常见 PHP Fatal error: Uncaught Error: Call to undefined function frankenphp_handle_request() 或 Allowed memory size exhausted），因为 WordPress 根本没引入 FrankenPHP 的 runtime 扩展，也没做任何适配。
正确做法是：对 WordPress，只用 FrankenPHP 的**普通模式**（即默认模式），它等价于 Nginx + PHP-FPM，但省去了 socket 配置和进程管理。Caddyfile 中只需：
localhost {
php {
root * /var/www/wordpress
import php_fastcgi
}
}其中 php_fastcgi 是 FrankenPHP 内置指令，自动处理 FastCGI 协议转发，无需额外配置 PHP-FPM。
想提升 WordPress 性能？别碰 Worker，换别的路
Worker 模式对 WordPress 是无效且危险的路径。真正有效的优化点集中在：
- 启用 OPcache 并调大
opcache.memory_consumption（至少 256M） - 用 Redis 或 Memcached 做对象缓存（通过
WP_REDIS_HOST环境变量接入） - 静态资源走 Caddy 原生缓存：
header Cache-Control "public, max-age=31536000"+file_server - 关闭无用插件，尤其是实时同步类（如 Jetpack 的 Stats）、可视化构建器（Elementor 的前端 JS 加载）
- 把数据库查询慢的日志打开，针对性优化 SQL 或加索引
FrankenPHP 对 WordPress 的价值，在于简化部署和统一 TLS/HTTP/3，不是靠常驻内存硬改框架。强行 Worker，就像给自行车装涡轮增压——零件不匹配，只会炸缸。
