根本区别在于php运行时是否跨请求存活：fpm每次请求都重建框架、连接和上下文，frankenphp worker模式仅复用类加载与配置解析，但静态变量、pdo实例等仍需手动清理，非真常驻。
FrankenPHP 的常驻运行（worker 模式）和传统 PHP-FPM 请求模式，根本区别在于「PHP 运行时是否跨请求存活」——前者让框架初始化、类加载、连接池等只做一次；后者每次请求都从头来一遍。
传统 PHP-FPM 是“进程常驻，应用不常驻”
PHP-FPM 的 worker 进程本身是常驻的，但每个请求进来后，仍会：重新 include 入口文件、重建 $_GET/$_POST、重新执行框架 bootstrap（如 Kernel::boot() 或 wp-settings.php）、新建 PDO 实例、重连数据库。即使开了 opcache，也只是跳过 opcode 编译，static 属性、全局变量、对象实例全都被销毁。
常见错误现象：Undefined variable 在第一次请求里能用，第二次就报错；数据库连接数随并发线性上涨；压测时 1000 QPS 就触发 MySQL 连接池耗尽。
- 配置依赖
php-fpm.conf中的pm.max_requests，值设小会导致频繁重启 worker，打断长连接 - 无法复用
Redis或PDO对象，哪怕加了PDO::ATTR_PERSISTENT，也受限于 FPM 进程回收策略 - HTTP/2 和连接复用由 Nginx 层管理，PHP 层无感知
FrankenPHP worker 模式是“伪常驻”，复用有限但可控
它复用的是 PHP-FPM 的进程池模型，但把整个 PHP 生命周期“拉长”到进程级：入口脚本只执行一次（如 public/worker.php），后续所有请求都通过 frankenphp_handle_request() 调度进同一个 PHP 进程。类定义、opcache 预加载、APCu 缓存都跨请求有效，但 static 变量、$GLOBALS、PDO 实例等仍需手动清理。
关键限制：frankenphp_handle_request() 不会自动重置运行时状态，你得自己在每次请求前 unset 大数组、close() 显式打开的资源、清空单例缓存。
- 没有
ResetInterface或类似钩子，必须显式调用apcu_clear_cache()或重置静态属性 -
opcache.preload生效，但new Redis()仍要写在onWorkerStart类似位置（实际靠worker.php入口一次性初始化） -
pm.max_requests依然起作用——FrankenPHP 会尊重 PHP-FPM 配置项，强制重启 worker 进程
Swoole 才是真常驻，FrankenPHP 不是它的替代品
别把 FrankenPHP worker 和 Swoole 的 onWorkerStart 混为一谈。Swoole 的 Worker 进程启动后，new Redis()、static::$cache、$db 全部天然跨请求存活；FrankenPHP 下这些对象每次请求后仍被销毁，只是“加载类”和“解析配置”的开销被省掉了。
性能差异最直观：Swoole 单个 Worker 处理 1000 次请求，数据库只连 1 次；FrankenPHP 是连 1000 次（除非你手动实现连接池并复用句柄）。
- FrankenPHP 无法支持
Co::sleep()或协程并发，curl_multi是唯一原生异步选项 - 不能在
frankenphp_handle_request()外部访问请求上下文（比如$_SERVER['REQUEST_URI']在 worker 启动时还没生成） - 共享内存只能靠
apcu_store()/shmop，且不支持存储资源类型（如mysqli句柄）
真正容易被忽略的点：FrankenPHP 的“常驻”收益高度依赖框架是否支持延迟初始化。Symfony 和 Laravel 的 HttpKernel 可以 boot 一次复用，但很多老项目把 DB 连接写在控制器里，worker 模式下反而会因残留连接引发 timeout —— 这时候不是换服务器的问题，是代码得改。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
