FrankenPHP默认单请求模式导致WordPress高并发时502，必须启用worker模式并改造代码：包裹wp-load加载、防护钩子重注册、显式缓存数据库查询，同时在Caddyfile中配置php_worker_count、max_requests及静态资源分离。
FrankenPHP 能顶住 WordPress 高并发活动页，但前提是别把它当 Nginx 用——它不是“另一个 Web 服务器”，而是要你把 PHP 生命周期管起来。
为什么默认 WordPress + FrankenPHP 依然会 502
很多人装完 FrankenPHP，直接把原 Nginx 的 root 和 index.php 复制进 Caddyfile，结果大促一来照样 502。根本原因不是 FrankenPHP 不行，而是它默认以“单请求模式”运行：每个请求都加载一次 WordPress 核心、初始化全部插件、重建对象容器——和 PHP-FPM 一样重复开销拉满。
这在日常流量下没问题，但面对 3000+ 并发时，CPU 全耗在 wp-settings.php 和 wp-includes/load.php 上，worker 进程卡死，响应队列溢出，Caddy 层直接返回 502。
- 必须启用
workers模式，让 PHP 进程常驻，跳过重复 bootstrap - WordPress 主题/插件里不能有
exit、die或未捕获的 fatal error，否则会杀死整个 worker -
wp-config.php中的define('WP_DEBUG', true)在高并发下会显著拖慢日志写入，务必关掉
worker 模式下必须改写的三个关键点
FrankenPHP 的 worker 模式不是“打开就加速”，WordPress 默认代码结构和它不兼容。以下三处不改，worker 就是纸老虎：
立即学习“PHP免费学习笔记（深入）”；
-
wp-blog-header.php开头的require_once(ABSPATH . 'wp-load.php');必须包裹在if (!defined('WP_SETUP_COMPLETE')) { ... define('WP_SETUP_COMPLETE', true); }里，防止多次加载全局变量污染 - 所有插件的
add_action('init', ...)初始化逻辑，要加! defined('WP_CLI') && ! defined('DOING_AJAX')判断，避免每次请求都重注册钩子 - 主题
functions.php中的数据库查询（如get_option()）必须显式缓存到$GLOBALS或wp_cache_set()，否则每次请求都查一次 MySQL
不改这些，worker 进程看似常驻，实则每次请求都在做无意义的重复初始化，吞吐量甚至不如调优后的 PHP-FPM。
Caddyfile 里最容易漏掉的性能开关
FrankenPHP 的 Caddyfile 不只是路由配置，它直接控制底层资源分配。这几个参数不显式设，等于没开 worker：
-
php_worker_max_requests必须设（比如1000），否则默认为 0，worker 永不重启，内存泄漏会越积越多 -
php_worker_count建议设为 CPU 核心数 × 1.5（例如 4 核设6），太少扛不住并发，太多抢 CPU 反而降低吞吐 - 静态资源路径必须用
file_server显式声明，不能依赖php指令兜底，否则 JS/CSS/图片也走 PHP 解析，白白消耗 worker - 加
encode zstd gzip，FrankenPHP 对 zstd 压缩支持比 gzip 更高效，尤其对 HTML 响应体
示例片段：
localhost:8080 {
root * /var/www/html
file_server
php /* {
root /var/www/html
worker_count 6
max_requests 1000
}
encode zstd gzip
}活动页专用优化：绕过 WordPress 主循环
活动页（比如倒计时+立即抢购）根本不需要 WP_Query、主题模板、侧边栏。硬套 WordPress 全栈流程是最大浪费。
更有效的做法是写一个独立入口文件（如 /var/www/html/act/flash-sale.php），只加载必要组件：
- 跳过
wp-blog-header.php，直接 requirewp-load.php+wp-includes/functions.php - 用
wp_cache_get()直接取预热好的商品库存、用户状态等数据，不走get_post_meta() - 响应直接
echo json_encode()或输出精简 HTML，不走template_redirect钩子
这种页面在 FrankenPHP worker 下可做到 sub-10ms 响应，QPS 突破 5000 完全可行——前提是 PHP 代码本身没写成“每次请求 new 二十个对象再 foreach 三次”。
真正卡住 FrankenPHP 的从来不是并发数，而是你有没有把 WordPress 从“每次请求启动一套系统”变成“只在需要时执行业务逻辑”。worker 模式不是魔法开关，它是把责任从框架转移到了开发者手上。
