結論先講
把 Auth 從 40% 降到 10%，排名完全洗牌。 Spring Boot 的 Tomcat thread pool 在讀取密集場景大放異彩，健康 VU 從 CRUD 的 50 飆到 1,000——提升 20 倍。如果你只看 CRUD 場景 就下結論「Spring Boot 很慢」，你會做出錯誤的技術選型。
為什麼這個場景比 CRUD 更接近真實
大部分 Web 應用的流量長這樣：
- 讀取 60-80%：瀏覽商品、看文章、查詢列表
- 寫入 15-30%：建訂單、發留言、更新資料
- 認證 5-15%：登入、註冊、token refresh
CRUD 場景 讓每個 VU 都跑 Register + Login，Auth 佔了 40%。那不是真實流量——現實中用戶登入一次，然後帶 JWT 做幾十次讀寫。
混合場景的 70/20/10 比例更接近現實。bcrypt 只影響 10% 的操作，框架自己的 I/O 處理能力才是主角。
排名對照
| # | 框架 | 混合 健康 VU | 混合 Max RPS | CRUD 排名 | 變化 |
|---|---|---|---|---|---|
| 1 | Spring Boot | 1,000 | 228 | 8th | +7 |
| 2 | Go | 500 | 120 | 1st | -1 |
| 3 | FastAPI | 100 | 113 | 6th | +3 |
| 4 | .NET Core | 0 | 122 | 2nd | -2 |
| 5 | Django | 0 | 163 | 9th | +4 |
| 6 | NestJS | 0 | 219 | 4th | -2 |
Spring Boot：+7 名
健康 VU 從 50 → 1,000（20 倍），Max RPS 從 16 → 228（14 倍）。
為什麼？三個原因：
- Tomcat 50 threads 終於有用了: CRUD 時 bcrypt 佔滿 CPU，threads 全在排隊。混合場景 70% 是讀取，threads 可以並行處理 I/O
- Hibernate L2 Cache: 重複讀取同一批 Post，第二次直接從 cache 拿
- JVM JIT: 長時間運行後 hot path 被優化，讀取操作的 overhead 極低
Go：-1 名但其實更強了
Go 的健康 VU 也從 100 → 500（5 倍提升）。只是 Spring Boot 提升得更多（20 倍）。
Go 輸 Spring Boot 的原因：GORM 沒有 L2 Cache（每次讀取打 DB），加上 DB pool 只有 20（Spring Boot 50）。
.NET Core、Django、NestJS：健康 VU = 0
這三個框架在 10 VU 時就超過健康標準（error rate > 5% 或 RPS/VU < 0.1）。但看 Max RPS：NestJS 219、Django 163、.NET Core 122——數字不低。
問題不是「框架慢」，是在 2 CPU 限制下，10% 的 Auth 操作（bcrypt）已經足以讓這些框架超標。回顧 容量規劃表：給 4 CPU 結果會完全不同。
這個翻盤告訴我們什麼
1. 框架選型不能只看 CRUD benchmark
很多網路上的「框架效能比較」只跑 Hello World 或 User CRUD。這些場景被 bcrypt 或框架 overhead 主導，和真實應用的效能差距很大。
2. 讀取為主的場景，JVM 最強
JVM 的 thread pool + JIT + Hibernate Cache 的組合在讀取密集場景下無敵。這是為什麼 Java 在企業級應用中統治了 20 年——大部分企業應用就是讀多寫少。
3. 「免費午餐」在混合場景效果更大
Redis cache 在讀多場景提升 6.5 倍。混合場景 70% 是讀取 → Redis cache 的效果在這裡最大。
下一篇
檔案上傳壓測：Streaming vs Buffering — 從 CPU-bound 的混合場景轉到 I/O-bound 的檔案上傳。Spring Boot 和 Go 並列第一（健康 VU 1,000），但上傳方式的差異讓 Express-TS 直接墊底。
本系列文章
完整 68 篇目錄見 系列首頁
← 上一篇：跨層容量規劃：從 10 人到 5000 人的技術選型地圖 → 下一篇：檔案上傳壓測：Streaming vs Buffering 的哲學之爭