Laravel vs Lumen：當 Laravel 自身變得足夠輕量，Lumen 還有存在的必要嗎？

Laravel vs Lumen：當 Laravel 自身變得足夠輕量，Lumen 還有存在的必要嗎？

在 PHP 生態系中，Laravel 毫無疑問是主流的 Web 框架之一。而在 Laravel 的發展歷程中，曾經有一個舉足輕重的衍生框架：Lumen。

過去幾年，面試官常問：「Laravel 與 Lumen 最大的差別是什麼？」

傳統標準答案通常是：

「Laravel 是完整 Web 框架，Lumen 是輕量版，適合 API 與微服務，而且效能更好。」

這個回答放在 Lumen 發展初期非常合理，但如果今天還拿這套邏輯做技術選型，就忽略了一個關鍵的生態變化：Lumen 已經不再是 Laravel 官方推薦的新專案方向。

Lumen 11 官方文件已明確標註：

“It is no longer recommended to start new projects using Lumen. Instead, new projects should be started using Laravel.”

本文將從 「Lumen 當初為何存在」、「Laravel 本身的極簡演進」 以及 「現代 PHP 架構的實務選型」 三個維度，深入解析這段技術演進背後的工程思維。

一、 Lumen 為什麼會出現？

理解 Lumen，必須先回到它誕生時所要解決的痛點。

Laravel 是一個功能極其豐富的全棧 Web 框架。一個預設的 Laravel 專案包含了 Session、Cookie、Blade、Queue、Event、Mail、Storage、Notification 等數十種功能。

但在微服務（Microservices）與 API-Only 架構興起時，許多服務只需要極少的元件：

[ 典型 API 服務需求 ]
HTTP Routing ──> Middleware ──> Validation ──> Database (Eloquent) ──> JSON Response

既然不需要 View、Session、Cookie 等完整 Web 功能，早期的思路非常直接：「能不能把不需要的功能抽掉，降低框架自身的啟動開銷（Framework Overhead）？」

Lumen 就是在此背景下誕生——作為一個獨立的框架，它保留了 Laravel 核心元件（Service Container、Middleware、Eloquent），但移除了高階整合與非必要套件，實現了極致的 Bootstrapping 速度。

二、 效能迷思：真正的 API 效能瓶頸，通常不在 Framework

「Lumen 比較輕，所以系統一定比較快」是許多工程師容易陷入的迷思。

在真實的工程環境中，一個 API Request（例如 GET /orders/123）的耗時組成通常如下：

  Framework Bootstrap  : 5 ms
  Application Logic    : 10 ms
  MySQL Query          : 80 ms
  Redis Cache          : 5 ms
  External API Call    : 150 ms
  Network Latency      : 20 ms
--------------------------------
  Total Time           : 270 ms

即使使用 Lumen 將 Framework Overhead 從 5 ms 壓到 2 ms，整體回應時間也只是從 270 ms 降至 267 ms，使用者體感幾乎為零。

相反地，優化 MySQL 查詢（80 ms $\rightarrow$ 20 ms）或 External API 呼叫（150 ms $\rightarrow$ 50 ms），能直接帶來數倍的效能提升。

成熟的架構優化順序應為：

$$\text{Database} \rightarrow \text{Network} \rightarrow \text{External API} \rightarrow \text{I/O} \rightarrow \text{Cache} \rightarrow \text{Application Logic} \rightarrow \text{Framework Overhead}$$

過早為了幾毫秒的框架開銷而放棄完整生態，往往是過度優化（Premature Optimization）。

三、 Laravel 自身的進化：它開始吸收「Lumen 式的精簡思想」

為什麼官方現在不再推薦 Lumen？因為 Laravel 本身已經變得足夠精簡。

1. Laravel 11 的 Skeleton 極簡革命

Laravel 11 重構了專案目錄結構（Application Skeleton），將許多以前散落在各地設定檔集中至 bootstrap/app.php。

預設的專案結構大幅瘦身：

• 移除了 Http/Kernel.php 與 Console/Kernel.php。
  
  
• 預設 Service Provider 簡化為僅剩 AppServiceProvider。
  
  
• 預設不載入 API 路由（routes/api.php）與廣播頻道。
  
  

如果你需要 API 功能，必須顯式執行：

Bash

php artisan install:api

執行後，Laravel 才會掛載無狀態（Stateless）的 API 路由與必要的認證機制。這種「按需啟用（On-Demand）」的設計，代表 Laravel 自身吸收了 Lumen 的精簡思想——不需要就不預載，保持核心極輕。

PHP

// Laravel 11 的極簡 bootstrap/app.php
return Application::configure(basePath: dirname(__DIR__))
    ->withRouting(
        api: __DIR__.'/../routes/api.php',
        health: '/up',
    )
    ->withMiddleware(function (Middleware $middleware) {
        // 預設無 Session、Cookie 等多餘 Middleware
    })
    ->create();

2. 常駐記憶體引擎：Laravel Octane 的降維打擊

過去 Lumen 靠「拔功能」省下的幾毫秒，在 Laravel Octane（結合 FrankenPHP / RoadRunner / Swoole）面前顯得微不足道。

傳統 PHP-FPM 模式下，每個 Request 都需要重新載入框架；而 Octane 採用常駐記憶體（In-Memory Process）機制：

【傳統 PHP-FPM】
Request ──> Bootstrapping (5~10ms) ──> Execute Controller ──> Destroy

【Laravel Octane】
Framework Bootstrapped (Only Once at Startup)
Request 1 ──> Execute Controller ──> Response (< 1ms)
Request 2 ──> Execute Controller ──> Response (< 1ms)

Octane 直接將 Bootstrapping 時間壓縮至 0.x 毫秒等級，吞吐量（RPS）提升 5~10 倍。這徹底終結了「Laravel 框架太重」的假議題。

四、 TCO 總成本計算：為什麼選 Lumen 往往不划算？

選型不該只看效能 Benchmark，更應評估 TCO（Total Cost of Ownership，總擁有成本）：

$$\text{TCO} = \text{Development Cost} + \text{Maintenance Cost} + \text{Infrastructure Cost} + \text{Team Onboarding Cost}$$

Lumen 雖然是 Laravel 衍生框架，但它與 Laravel 生態套件的相容性並非 100%。

當你在 Lumen 中需要 Authentication、Complex Validation 或第三方 Package 時，往往需要自行撰寫 Service Provider、適配 Config 或處理版本衝突。

• 選擇 Lumen：省下 3ms 執行時間 $\rightarrow$ 增加 30% 開發與升級維護成本。
  
  
• 選擇 Laravel：增加 3ms 執行時間 $\rightarrow$ 換取 100% 開箱即用的生態與維護效率。
  
  

五、 舊專案與微服務的正確處置觀念

1. Legacy Lumen 服務不用急著重寫

「不推薦新專案使用」不等於「舊系統必須立刻重寫」。

如果企業內部已有穩定運作的 Lumen 服務，正確的工程處置方式是：

$$\text{維持運作} \rightarrow \text{跟進升級至 Lumen 11 (Maintenance Release)} \rightarrow \text{有大規模需求變更時再進行 Migration}$$

2. 微服務（Microservices）是架構，不是框架

「微服務 = Lumen」是常見的認知誤區。微服務的核心在於服務邊界劃分（Service Boundary）與獨立部署。使用 Laravel + Docker + Redis + Queue 建立微服務完全合情合理且極易維護。

六、 現代技術選型決策樹（2026 年標準）

新專案請直接採用以下決策流程：

                       【新專案技術選型】
                               │
            ┌──────────────────┴──────────────────┐
            ▼                                     ▼
   需要利用 PHP / Laravel 生態              極致 I/O 導向 / 非 PHP 領域
            │                                     │
            ▼                                     ▼
    直接選用 Laravel 11+                    考慮 Go / Rust / Node.js
 (下指令: install:api)
            │
            ├─► 一般 API / Web 應用 ───► Standard PHP-FPM
            └─► 極高併發 / 低延遲    ───► Laravel Octane (FrankenPHP)

結語

Lumen 的歷史使命已經圓滿完成。它並未失敗，而是它的精簡哲學已經被母體 Laravel 吸收，同時被現代 PHP Runtime 與 Octane 等常駐記憶體方案所超越。

軟體工程中最寶貴的思維是：理解一個技術當初為什麼存在，並理解今天為什麼不再需要它。

對今天的新專案而言，問題不再是「要選 Laravel 還是 Lumen？」，而是：

「當 Laravel 本身已經足夠精簡且高效，我們還有什麼理由需要另一個衍生框架？」