FrankenPHP 正式進入 PHP 基金會：Laravel 工程師應該知道的「PHP 第三種跑法」

PHP 在 2026 年最重要的一件事，不是 Laravel 12 又多了哪幾個新功能，而是 FrankenPHP 正式被納入 PHP Foundation 的旗艦專案。對長期用 Laravel + Nginx + PHP-FPM 經營網站的團隊來說，這意味著效能戰場的座標被換了。

過去十年，PHP 的部署模型幾乎都是同一個：Nginx 把請求丟給 PHP-FPM，PHP 進程處理完後關閉，下一個請求再重新初始化 Laravel framework。這個「請求—銷毀—再初始化」的模式很安全，但也意味著每一次請求都要付一筆固定的啟動成本：把 service container 重組、把 config 重新讀進來、把 ServiceProvider 全部跑一輪。對中小型 SaaS 來說這沒有什麼大不了，但當你的 Laravel 應用每天處理數百萬次 API 呼叫時，這筆成本是肉眼可見的。

FrankenPHP 把這件事換掉了。它本身是用 Go 寫的 application server，內建 Caddy 作為 HTTP 入口，並提供 worker mode — 也就是 Laravel framework 只在 worker 進程啟動時被初始化一次，之後的每一個請求都共用同一個已經暖機過的 Laravel 實例。這跟 Python 的 Gunicorn、Node.js 的 cluster、或者 PHP 圈先前的 Swoole/RoadRunner 思路一致，但 FrankenPHP 的賣點是它不需要重寫程式碼 — Laravel Octane 已經有 FrankenPHP driver，社群實測 RPS 平均能跳 3 到 5 倍。

更重要的是「正式進入 PHP Foundation」的意義：這代表 FrankenPHP 不再是某個個人開源專案的單點命運，它跟 Composer、PHPStan、Xdebug 一樣，現在有基金會層級的維護承諾。對企業客戶來說，這把 worker mode 從「酷但風險高」推到了「可以寫進採購規格」的位置。

對 Flutter App 開發外包商來說，這條新聞也很有意義。Flutter App 通常需要一個 PHP/Laravel 後端提供 API，過去最大的延遲瓶頸往往是 PHP 開機成本而不是 MySQL 本身。把後端從 PHP-FPM 換成 Octane + FrankenPHP，App 端的 cold call 延遲常常可以從 250–400ms 降到 60–90ms — 這個數字對用戶體驗的提升，比起重新寫 UI 動畫還明顯。

部署面，Nginx 的角色開始改變。許多新團隊正在把 Nginx 從「PHP 前端反代」改為「TLS 終端 + 多後端負載平衡」，而把 FrankenPHP/Caddy 放在內網處理請求 worker。如果你還在維護傳統 Nginx + PHP-FPM 架構，現在這個時間點重新評估，是 2026 年最值得投資的一場架構改造。

但有兩個必須提醒的雷：第一，worker mode 會「記憶」全域變數的污染，舊式的 Laravel 套件如果沒有妥善 release container binding，會在第二個請求出現詭異 bug；第二，記憶體使用會明顯上升，建議用 Octane 的 --max-requests 參數讓 worker 週期性重啟。

我的觀點

PHP 從來不缺新框架，它缺的是「效能可以講得出口」的部署故事。FrankenPHP 解決的不只是技術問題，更是商業問題 — 當客戶問你「為什麼一樣是 API 後端，要用 Laravel 而不是 Node.js」時，現在你可以說：「我跑 worker mode，每秒 4000 個請求，比 Express 還快。」這是過去十年第一次，PHP 工程師可以直接用效能指標對話，而不是用「開發速度」或「人才好找」去防守。

FrankenPHP 正式進入 PHP 基金會：Laravel 工程師應該知道的「PHP 第三種跑法」

我的觀點

資料來源