Discuz! X3.5 有必要上 FrankenPHP 来提升性能吗？

IsaacZ

结论先行：没有必要，至少不值得为此折腾。

你的场景是 Discuz! X3.5 + 雷池 WAF + 宝塔 Nginx + PHP-FPM 的成熟环境，当前运行的瓶颈（数据库、插件、I/O）FrankenPHP 解决不了，而它的核心优势（Worker 模式）Discuz! 也用不上。

为什么 FrankenPHP 对你提升不大

1. Worker 模式是 FrankenPHP 的“王牌”，但 Discuz! 用不了

FrankenPHP 真正的性能飞跃来自 Worker 模式（框架常驻内存，省去每次请求的初始化）。Laravel/Symfony 这类框架受益明显，吞吐量能提升 3-10 倍。但 Discuz! 不是为常驻内存设计的，你只能用它的经典模式（经典模式只是替代 PHP-FPM，性能几乎没有差别）。

官方论坛里 X5 的讨论也明确说“只有 x5 能用，x3.5 不能用”（Worker 模式）。

2. 经典模式 vs PHP-FPM：性能几乎一样

有实测对比 FrankenPHP 经典模式和 Nginx + PHP-FPM 8.4 的性能，简单 HTML 场景下 RPS 分别是 6934 vs 7023，差异仅 1.3%。另一份测试的 “Hello World” 场景两者都约 1.85 万 RPS，差异 0.4%。结论很直白：经典模式下，运行时本身不是决定性因素，瓶颈在业务和 I/O。

3. 你的瓶颈不在 PHP 运行时

根据你的 env-base，你做过这些优化：IndexNow 异步、垃圾回复拦截、邮件队列、图片本地化。论坛卡顿的根源从来都是数据库查询、插件钩子、外部 API 调用。换 Web 服务器对这些问题毫无帮助。

4. 你已有雷池 WAF，架构清晰

FrankenPHP 自带 Caddy 服务器，但你的流量链路是：用户 → 雷池 WAF（Tengine）→ 宝塔 Nginx → PHP-FPM。引入 FrankenPHP 意味着要么替换宝塔 Nginx（丢失宝塔面板的站点管理便利），要么在雷池后面再串一层（架构更复杂）。

值得考虑的真正理由（和性能无关）

FrankenPHP 的优势在别处：

特性	对你是否有用
单二进制，一个进程	如果你讨厌管 Nginx + PHP-FPM 两套配置，有点吸引力
自动 HTTPS / HTTP/3	你已有雷池处理 SSL，不需要
Early Hints（HTTP 103）	对 Discuz! 模板优化可能有微小帮助，但性价比低
Mercure 实时推送	对论坛的实时通知场景有点意思，但 Discuz! 生态不集成

风险提示

FrankenPHP 在生产环境有已知坑：

• PHP 错误会导致整个 Web 服务器挂掉，需要 SSH 重启
• imagick 扩展的 OpenMP 线程会与 FrankenPHP 冲突导致崩溃（Discuz! 处理图片常用）
• 某些版本（如 v1.12.0）的 OPcache preloading 存在崩溃/挂起问题
  

最终建议

保持现状，把精力花在真正的瓶颈上（数据库索引、慢查询、插件钩子）。如果你只是好奇想试，可以在本地或测试环境用 Docker 跑一个 FrankenPHP + Discuz! X3.5 的经典模式，测一测发帖、回帖的 TTFB，和现有环境做个对比。但我几乎可以确定，数字不会有实质变化。


- by DeepSeek