結論先講
同一家公司在不同階段可能需要不同框架。 50 人用 Django 起步、500 人用 NestJS 重寫核心、5000 人把最熱的 API 用 Go 拆出來。不是一開始就要選到「最終答案」，而是每個階段選「當下最合適的」。
案例一：50 人內部系統
需求
- 公司內部的進銷存管理
- 同時在線 < 50 人
- 需要 Admin 後台讓非工程師操作
- 團隊 2 人，都會 Python
決策矩陣
| 維度 | Django | Express-TS | Go |
|---|---|---|---|
| 團隊能力 | 5（都會） | 3 | 1 |
| 硬體預算 | 4（2 CPU 夠） | 4 | 5 |
| 生態需求 | 5（Admin 開箱即用） | 3 | 1 |
| 壓測效能 | 3（50 人夠用） | 4 | 5 |
| 加權總分 | 4.25 | 3.5 | 3.0 |
選 Django
- Django Admin 省掉 2-4 週的後台開發時間
- 50 人壓力下 2 CPU 夠用（容量規劃表）
- 加 Redis cache 可以延長壽命到 100-200 人
- 不需要微服務——單體 + Docker Compose 就好
案例二：500 人 SaaS 產品
需求
- B2B SaaS，客戶數在成長
- 同時在線 200-500 人
- 需要 REST API + WebSocket 通知
- 團隊 5 人，3 個 JS、1 個 Python、1 個 DevOps
決策矩陣
| 維度 | NestJS | Express-TS | FastAPI | Go |
|---|---|---|---|---|
| 團隊能力 | 5（3 人會 JS） | 5 | 3 | 1 |
| 硬體預算 | 4 | 4 | 4 | 5 |
| 生態需求 | 5（DI + Swagger + TypeORM） | 3 | 3 | 2 |
| 壓測效能 | 3 | 4 | 3 | 5 |
| 加權總分 | 4.25 | 4.0 | 3.25 | 3.25 |
選 NestJS
- 結構化的 DI + Module 系統適合 5 人團隊協作
- Swagger 自動生成（B2B SaaS 需要 API 文件給客戶）
- WS/SSE 壓測顯示 500 VU 零錯誤（第 26 篇）
- PM2 cluster × 4 在 500 人壓力下夠用
- 架構：NestJS + PM2 + nginx + Redis + PG
到 1000 人時怎麼辦
不用換框架。按 免費午餐 順序做：
這些組合可以把 NestJS 撐到 1000-2000 人。
案例三：5000 人電商
需求
- ToC 電商，有大促活動
- 平日 1000 人、大促 5000 人
- 需要高併發 API + 即時庫存 + 推播通知
- 團隊 15 人，混合背景
決策
這個規模不適合只用一個框架。按 容量規劃表 的 5000 人建議：
核心 API（商品/訂單/庫存）→ Go
- 理由：全程零錯誤到 10K VU、goroutine 適合高併發
- 團隊：分配 3-4 個工程師學 Go
後台管理 + CMS → NestJS
- 理由：CRUD 為主，NestJS 的 DI + Swagger 適合
- 團隊：3-4 個 JS 工程師
推薦系統 / 搜尋 → FastAPI
- 理由：Python ML 生態整合
- 團隊：2 個 Python 工程師
基礎設施
- nginx 叢集 + Redis cache + Kafka（事件驅動）
- PG 主 DB + 讀寫分離
- K8s（5000 人需要自動擴縮，[[micro-service/22-infra-scaling-and-k8s|第 22 篇]]）
為什麼不全用 Go
15 人全學 Go 不切實際。而且後台管理系統不需要 Go 的效能——NestJS 在管理後台（同時 10-50 人）綽綽有餘。
不同 service 用不同框架是微服務的優勢之一。每個 service 選最適合它的技術，而不是全部統一。
共同的模式
三個案例有一個共同點：從壓測數據反推硬體需求，從硬體成本和團隊能力做最終決策。
不是「Go 最快所以選 Go」，而是：
- 我的場景需要撐 N 人
- 壓測數據說框架 X 在 M CPU 上能撐 N 人
- M CPU 的成本是多少
- 團隊學框架 X 的成本是多少
- 總成本最低的那個，就是答案
下一篇
微服務拆分時機：什麼 UV 該拆、什麼時候不該拆 — 壓測數據告訴你「單體能撐多少人」。加上免費午餐能再撐 13 倍。超過這個數字才需要拆。大部分應用其實不需要微服務。
本系列文章
完整 68 篇目錄見 系列首頁
← 上一篇：框架選型方法論：團隊能力 × 硬體預算 × 生態需求 → 下一篇：微服務拆分時機：什麼 UV 該拆、什麼時候不該拆