php/frankenphp

当你的 PHP 应用已经跑在 nginx 和 PHP-FPM 后面、想用一个进程一套配置完成部署，FrankenPHP 值得花时间评估。但它不是读完 README 就能无痛替换的，迁移指南和已知问题页要先看。

解决什么问题

常见的 PHP 部署把职责拆开：nginx 负责 TLS、静态文件和反向代理，PHP-FPM 负责跑进程池，而 PHP 经典的按请求生命周期让每次请求都重新做一遍启动工作。想改变这套结构，就得同时动两份配置、两个服务和一套 TLS 方案。FrankenPHP 把 Web 服务器和 PHP 合并进同一个二进制：同一个进程接收请求、执行处理逻辑并返回响应。应用代码大体不变，变的是部署方式和请求模型。

有什么不同

FrankenPHP 把 PHP 嵌进一个基于 Caddy 的 Go 进程 项目说明Caddy。Caddy 带来自动 HTTPS 以及 HTTP/2、HTTP/3 支持 项目介绍，worker 模式下 PHP 只初始化一次，而不是每个请求都初始化 worker 模式文档。文档给出的收益是 Laravel 和 Symfony 可以使用官方 worker 集成；代价是长驻 worker 会改变你对状态的思考方式，应用代码和扩展必须适配这种模式。经典模式则保留接近 PHP-FPM 的按请求生命周期 经典模式文档，所以迁移是模式选择，而不是全有或全无。

服务器核心之外，还有 Early Hints Early Hints、基于 Mercure 的实时推送 实时推送 和开发用热重载 热重载。FrankenPHP 也能作为 Go 库，把 PHP 嵌进 net/http 应用 Go 库；这是另一种用法：PHP 成为 Go 服务里的实现细节，而不是你指向现有项目的服务器。

最重要的取舍是范围：把路由、TLS、静态文件、WebSocket 式推送和 PHP 运行时放进一个二进制，减少了活动部件，但也意味着你的 Web 服务器配置变成 FrankenPHP 的 Caddyfile，而不是许多团队已经熟悉的 nginx 配置。迁移指南正是为此而写 迁移指南。

谁值得试

适合：一个在 nginx 加 PHP-FPM 上跑 Laravel、Symfony、WordPress 或 Drupal 的团队，希望单一可部署服务器、自动 TLS 和 worker 模式，并且愿意在持久 worker 下测试应用。框架指南覆盖 Symfony、Laravel 和 WordPress，社区集成还覆盖 Drupal、Joomla、TYPO3、Magento 2 和 WoltLab。

不适合：需要精确 nginx 配置、依赖按请求 SAPI 假设，或无法为持久 worker 做状态泄漏测试的团队。装了大量第三方插件的 WordPress 尤其要谨慎，经典模式能保留通常的生命周期。

使用条件与边界

安装路径不止一种，不存在单一硬性要求：shell 或 PowerShell 安装脚本 安装脚本、内置 PHP 8.5 的独立二进制 发布页、维护者提供的 rpm、deb 和 apk 包、Homebrew Homebrew 以及 Docker 镜像 Docker 镜像。扩展可用性因渠道而异：打包渠道通过同一仓库安装 php-zts-<extension>，其他扩展走 PIE PIE。选定安装渠道前，先核对你实际需要的扩展。

两个长期约束值得注意。第一，worker 模式是行为变化，需要检查状态和扩展假设，项目为此维护了已知问题页 已知问题。第二，生产部署、性能调优和可观测性各有文档 生产部署性能调优可观测性：这是需要你持续运维的服务器，不是加进项目就忘的库。若要从源码编译，另有专门指南 源码编译。

HotRepo 点评

HotRepo 只有一条带日期的观察：2026-10-26 的 Go 周榜第 12 名，当周 +67 星，没有可比的日榜历史。这只是快照，不足以判断持续性。真正要决定的是：确认计划使用的安装渠道里有你的应用所需的扩展，再在 worker 模式下测试应用，然后才切换流量。