frankenphp性能瓶颈在于是否启用worker模式：经典模式每请求重启php生命周期，laravel框架初始化开销大；worker模式复用已加载容器，需显式配置frankenphp_worker块并配合octane，否则qps无法质变。
并发上不去，先查 php_server 是否启用了 worker 模式 —— 经典模式（即默认的 FastCGI 兼容模式）下，FrankenPHP 仍是每请求 fork 一次 PHP 生命周期，Laravel 的容器初始化、服务注册、配置加载全得重来，压测时 CPU 花在 bootstrap 上，QPS 自然卡在瓶颈里。
确认你跑的是经典模式还是 Worker 模式
FrankenPHP 有两种运行方式，性能差距极大，但启动命令和 Caddyfile 看起来几乎一样，容易误判：
- 经典模式：用
php_server指令，不加任何额外参数，行为接近 Nginx + PHP-FPM，零改动就能跑 Laravel，但不提速 - Worker 模式：必须显式启用
frankenphp_worker，且 Laravel 需装laravel/octane并改写入口逻辑，框架只初始化一次，后续请求复用已加载的容器
检查当前配置是否在用 Worker 模式：
看 Caddyfile 里有没有类似这样的块：
localhost {
root public/
php_server { try_files {path} index.php }
frankenphp_worker { ... }
}
没有 frankenphp_worker 块，就只是经典模式 —— 此时再怎么调 Caddy 并发参数、加大内存，QPS 也不会有质变。
经典模式下压测前必做的三件事
即使不切 Worker 模式，经典模式也得把基础配置拉齐，否则 AB 或 JMeter 一压就崩或假慢：
-
APP_DEBUG=false：开发模式下 Whoops 渲染堆栈每次请求多耗 50–200ms，且吃内存 -
php artisan config:cache && php artisan route:cache：避免每次请求都重新解析 config/ 和 routes/ 目录下的 PHP 文件 - 确保 OPcache 已启用且生效：
frankenphp php-cli -i | grep opcache看opcache.enable是不是On，特别注意opcache.jit_buffer_size建议设为256M（FrankenPHP 内置 PHP 8.5 默认带 JIT）
漏掉任意一项，ab -c 100 就可能大量失败或响应时间抖动严重，这不是 FrankenPHP 的问题，是 Laravel 还在“开发态”裸奔。
Worker 模式下最容易被忽略的泄漏点
切了 Worker 模式后 QPS 上去了，但跑几分钟就开始内存上涨、请求变慢？大概率是状态泄漏：
- 全局变量（
$GLOBALS、static属性、闭包引用）没在每次请求后清理，会跨请求累积 - 数据库连接未显式关闭，PDO 实例被常驻进程持有，连接数缓慢爬升直至超限
- 日志处理器（如
SingleWriter）没切换成异步驱动，多个 worker 共享一个文件句柄导致阻塞
Laravel 官方 octane 包会在每次请求结束时自动清空部分上下文，但如果你手动用了 frankenphp_worker + 原生入口，这些事就得自己兜底 —— 别指望 php_server 会帮你做请求隔离。
真正卡并发的地方，往往不在 Caddyfile 的 max_conns 或系统 ulimit，而在你没意识到 Laravel 正在反复启动自己。Worker 模式不是开关，是契约：你承诺无状态，它才敢复用。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
