Worker模式适合框架启动开销大、请求间状态可安全复用、I/O等待占比高的PHP项目；ThinkPHP/Laravel/Symfony等重框架受益最明显，QPS可提升2–3倍；纯API服务比带Session的Web应用更适配，但需严格清理跨请求状态。
Worker模式适合哪些PHP项目
Worker模式不是“开就变快”，而是针对特定负载特征的优化手段。它只在满足三个条件时收益明显：框架启动开销大、请求间状态可安全复用、I/O等待时间占比高。不满足这些的项目，强行开启反而可能引入内存泄漏或状态污染。
ThinkPHP/Laravel/Symfony 这类重框架最受益
它们的引导过程（autoloader注册、服务容器初始化、配置加载、路由编译）占单次请求耗时 30%–60%。Worker模式让这部分只执行一次，后续请求直接复用已构建的对象实例。实测中，ThinkPHP 6/8 在 FrankenPHP 的 worker 模式下 QPS 提升 2–3 倍，Laravel Octane 也是同理。
-
frankenphp_handle_request()包裹$app->http->run()后，框架不再每次重建 HTTP kernel - 数据库连接、Redis 客户端、日志处理器等长生命周期对象可被复用，但必须确保它们本身是线程安全的
- 注意：
runtime/目录必须可写，否则缓存文件无法生成，反而导致重复编译路由和配置
CodeIgniter 4 4.7.0+ 可用，但需谨慎评估
CI4 的 Worker Mode 是实验性特性（versionadded: 4.7.0），官方明确只支持 FrankenPHP 作为后端。它依赖手动调用 $request->reset() 和 $response->reset() 来清理超全局变量和响应体，稍有遗漏就会出现跨请求数据残留。
- 常见坑：
$_SESSION、$_COOKIE、静态属性、单例类内部状态不会自动清空 - 必须检查所有自定义中间件、钩子（hooks）、服务类是否显式重置了请求级上下文
- 不建议在 CI4 中直接复用
base_url()或current_url()的返回值，因为它们可能缓存了上一个请求的 URI
纯 API 服务比带 Session 的 Web 应用更适配
Worker 模式天然规避了 PHP-FPM 的进程隔离，但也放大了状态管理风险。带用户登录态、Session 写入、CSRF Token 生成的 Web 页面，若未做严格请求隔离，容易出现 token 错乱、用户信息串话等问题。
立即学习“PHP免费学习笔记（深入）”；
- 推荐先用无状态 API（如 JSON-RPC、RESTful 接口）验证 worker 稳定性
- 如果必须跑带 Session 的页面，确保使用 Redis 或 Database 驱动的 Session，并禁用
session_start()的自动启动（改用按需开启） - FrankenPHP 的
php_ini session.auto_start 0配置项必须显式设置，不能依赖 php.ini 默认值
真正难的是“状态清理”——不是能不能跑起来，而是跑 1000 次之后，第 1001 次会不会因为某个没 reset 的静态数组而崩掉。这点比性能数字重要得多。
