FrankenPHP适合中大型Laravel项目解决特定瓶颈，如框架启动慢、配置分散、需HTTP/3或Mercure但不想搭反向代理；小项目则易增维护负担。
中大型 Laravel 项目值得上 FrankenPHP，小项目反而可能增加维护负担。 它不是“越新越好”的玩具，而是为解决特定瓶颈设计的——比如你正被 PHP-FPM 的重复初始化拖慢接口、被多层配置搞晕、或需要 HTTP/3 + TLS 自动管理但不想搭整套 Caddy + FPM。
哪些信号说明你的 Laravel 项目该考虑 FrankenPHP
出现以下任意一种情况，FrankenPHP 就不是“可选”，而是“值得投入时间评估”：
- 压测时
php artisan octane:status显示平均启动耗时 >30ms（Laravel 框架加载+服务提供者注册阶段） - Nginx 和 PHP-FPM 配置分散在至少 3 个文件里，每次改 HTTPS 或重写规则都要来回核对
- 你已经在用
php artisan route:cache/config:cache，但接口 P95 响应仍卡在 120ms 以上，且 CPU 利用率未达瓶颈 - 需要快速支持 HTTP/3 或 Mercure 推送，但不想额外维护一套反向代理或消息网关
小项目用 FrankenPHP 反而容易踩坑
如果你的 Laravel 项目满足以下任一条件，经典模式（非 Worker）收益有限，Worker 模式则大概率要返工：
- 日均请求量
- 代码里大量使用全局变量、静态属性缓存、
$_SESSION或未封装的数据库连接直连 - 依赖某些仅在 CLI 模式下初始化的扩展（如部分旧版
sqlsrv驱动），而 FrankenPHP 的嵌入式 PHP 运行时未启用对应 SAPI - 部署环境受限，无法运行 Go 编译的二进制（如某些老旧 ARMv7 容器或只允许 RPM 包安装的政企内网）
Worker 模式不是性能开关，而是架构约束
开启 frankenphp worker 后，PHP 进程常驻内存，框架只初始化一次——但这也意味着你必须遵守无状态契约：
立即学习“PHP免费学习笔记（深入）”；
- 所有请求间不能共享
static $cache或global $db这类跨请求污染的数据 -
AppServiceProvider::boot()里不能做一次性资源绑定（比如DB::listen()注册监听器需改用事件订阅） - Session 存储必须走外部驱动（Redis、DynamoDB），不能依赖文件或数据库表的本地锁机制
- 哪怕只有一处
exit、die或未捕获的Fatal error，整个 worker 进程就会退出，触发重启抖动
真正决定是否上 FrankenPHP 的，从来不是项目“有多大”，而是你是否愿意为性能让出一部分开发自由度，并接受它把 Web 服务器、PHP 运行时、TLS 终止全部耦合进一个进程的事实——这个耦合是优势，也是边界。
