wordpress在frankenphp worker模式下需替换默认index.php为专用worker.php入口，禁用exit/die/wp_die，重置全局变量，配置caddy重写规则，并启用opcache共享内存。
WordPress 在 FrankenPHP 的 Worker 模式下不能直接用默认的 index.php 作为 worker 入口，它本身不支持常驻进程生命周期，必须做适配才能稳定运行。这不是 WordPress 功能缺陷，而是架构差异导致的必然要求。
必须改用专用 worker 入口脚本
FrankenPHP 的 Worker 模式要求入口文件长期驻留、复用 Kernel 和连接，而 WordPress 默认的 index.php 是为“一次请求、一次退出”设计的，里面包含多个 exit、die 和隐式终止逻辑（如 wp_die() 调用底层 exit）。一旦启用 worker 却未替换入口，首次请求后 worker 进程大概率崩溃，后续请求全部失败。
- 需新建
public/worker.php，内容结构类似 Symfony 官方模板：外层初始化 WP 核心（require_once 'wp-load.php'等），内层用frankenphp_handle_request()包裹请求处理逻辑 - 禁止在入口或任何被加载的 WP 文件中调用
exit、die或未捕获的wp_die()；应统一转为返回 HTTP 响应对象或抛出可捕获异常 - 确保
wp-settings.php及插件初始化只执行一次，避免重复注册钩子、重载配置
状态清理比普通模式更关键
Worker 模式下所有请求共享同一 PHP 进程内存空间，WordPress 中大量依赖全局变量（$wp_query、$wp_rewrite、$_POST）、静态属性（如某些缓存类）和单例服务（如 WP_Http 实例），若不清除，极易出现跨请求数据污染——比如上一个用户看到下一个用户的后台页面、分页参数错乱、AJAX 返回旧数据等。
- 每次请求前手动重置关键全局：例如
$wp_query = new WP_Query();、wp_reset_query();、wp_reset_postdata(); - 禁用自动启动 Session：
ini_set('session.auto_start', '0');，改用按需session_start()并在请求结束时session_write_close() - 检查插件是否含静态缓存（如
static $cache = [];）、未关闭的数据库连接或未 reset 的 WP_HTTP 实例
Caddyfile 配置与重写规则不可省略
FrankenPHP 不读取 .htaccess，WordPress 的固定链接、REST API 路由、多站点子目录等全部依赖 Caddy 的重写规则驱动，漏配会导致 404 或无限跳转。
- 必须启用
php { worker /path/to/public/worker.php }，而非php_fastcgi - 固定链接需加 rewrite：例如
rewrite * /index.php?{query}，并确保该规则在 php 指令之前生效 - 多站点子域名模式要配合 Caddy 的
handle分支和 Host 匹配，不能依赖 WP 自动识别HTTP_HOST
性能收益有边界，别高估 Worker 的作用
FrankenPHP + Worker 对 WordPress 的加速主要来自抹除框架引导开销（约 30–50ms），但实际响应时间仍由数据库查询、主题渲染、第三方 API 调用等决定。如果站点已严重依赖慢 SQL、未优化的插件或同步外部请求，开启 Worker 后 QPS 提升有限，甚至因状态残留引发更多错误。
- 建议先用
curl -o /dev/null -s -w '%{time_total}\n'测 baseline，再对比开启前后真实接口耗时 - 搭配
frankenphp_metrics查看frankenphp_busy_threads和frankenphp_queue_depth，持续高位说明 worker 卡死，不是性能问题而是代码阻塞 - OPcache 必须启用且共享内存段由 FrankenPHP 统一管理，否则类加载开销仍存在
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
