結論先講
不是選最快的，是選讓你和你的團隊跑最快的。 68 篇文章跑完，最大的發現不是哪個框架最快——是「配置和查詢方式的影響遠大於框架選擇」。Go 比 Django 快 4-5 倍，但調好 pool + bulk + Redis 能提升 13 倍。你在技術選型上糾結的那一週，不如花在把現有系統的免費午餐做完。
這是整個系列的最後一篇。以下是三種團隊規模的完整推薦。
小團隊（3 人、< 100 用戶）
關鍵字：快速交付、低維護、一個人要能全包。
推薦技術棧
| 層 | 選擇 | 原因 |
|---|---|---|
| F2E | Vue 3 + Vite | 學習曲線最低、單檔案元件開發體驗好 |
| B2E | FastAPI | Python 生態好上手、自動產生 API 文件、和 ML 接軌 |
| DB | PostgreSQL | 通用型最強、JSONB 減少加 MongoDB 的需求 |
| Cache | Redis（視需要） | 100 用戶以下可能不需要，但加了也不虧 |
| Infra | Docker Compose + nginx | 一個 docker compose up 搞定全部 |
為什麼這樣選
Vue 3 而不是 React：3 人團隊不需要 React 的龐大生態，Vue 的 Composition API 更直覺，上手更快。[[micro-service/63-conclusion-f2e|#63]] 的結論是前端差距只有 6 分，選開發速度最快的。
FastAPI 而不是 Express：Python 的資料處理生態（pandas、scikit-learn）在小團隊的 side project 中更有彈性。如果確定不碰 ML，Express-TS 也是好選擇。
Docker Compose 而不是裸跑：即使是小團隊，環境一致性也很重要。但絕對不要碰 K8s——[[micro-service/67-conclusion-infra|#67]] 的數據顯示 1000 人以內 K8s 沒有優勢。
效能調校重點
- PG pool size 調到 20（預設太小）
- FastAPI 跑在 gunicorn + uvicorn worker 上（利用多核心）
- nginx 開 keepalive + gzip
- 就這三個，先做完再說
中團隊（5-10 人、500 用戶）
關鍵字：型別安全、可維護、開始有分工。
推薦技術棧
| 層 | 選擇 | 原因 |
|---|---|---|
| F2E | React + Next.js | 生態最大、SSR/SSG 彈性高、招人容易 |
| B2E | NestJS 或 Express-TS | TypeScript 全端統一、Node.js 生態最豐富 |
| DB | PostgreSQL | 加上適當的 Index 和 Bulk Insert |
| Cache | Redis | 500 用戶讀取壓力開始大，Redis 是必要的 |
| Infra | Docker Compose + nginx LB + PM2 | 2 台 App Server 做 load balancing |
為什麼這樣選
React + Next.js：5-10 人開始有前後端分工，React 的招人優勢開始重要。Next.js 的 SSR/SSG/ISR 讓你不用在渲染策略上做不可逆的選擇。
NestJS / Express-TS：[[micro-service/64-conclusion-b2e|#64]] 的結論是 Express-TS 每個場景都在前四名。NestJS 多了 DI + 模組化架構，5 人以上開始需要這種約束來降低溝通成本。
PM2 cluster：[[micro-service/21-infra-free-lunch|#21]] 的免費午餐第一項就是 multi-worker，+93% 效能不用白不用。
效能調校重點
- Tier 1 全做完：keepalive + worker + pool (50) + bulk + index
- Redis cache：至少 cache 首頁、列表頁、高頻 API
- 水平擴展到 2 台：+53% 效能，nginx round-robin
- 搜尋量大才加 ES，不要預裝
不要做的事
- 不要拆微服務——500 用戶的 monolith 加 Redis 就能跑得很順
- 不要上 K8s——Docker Compose + PM2 的維護成本是 K8s 的十分之一
- 不要做讀寫分離——[[micro-service/65-conclusion-db|#65]] 說了，這是最後手段
大團隊（15+ 人、5000+ 用戶）
關鍵字：效能敏感、服務拆分、需要自動化運維。
推薦技術棧
| 層 | 選擇 | 原因 |
|---|---|---|
| F2E | React + Next.js | 大團隊需要穩定生態和豐富套件 |
| B2E 核心路徑 | Go (Gin) | 高併發 API、低延遲、Cold Start 6.7s |
| B2E Admin/後台 | NestJS | 快速開發管理功能、TypeScript 型別安全 |
| DB | PostgreSQL Cluster | Primary + Read Replica |
| Cache | Redis Cluster | 多節點高可用 |
| 搜尋 | Elasticsearch | 中文分詞 + 模糊搜尋 |
| 事件流 | Kafka | 服務間解耦、事件驅動 |
| Infra | Kubernetes | 自動擴縮 + 零停機部署 |
為什麼這樣選
Go 核心 + NestJS 後台：[[micro-service/64-conclusion-b2e|#64]] 的跨場景排名顯示 Go 在高併發場景穩定第一。但不是所有服務都需要 Go 的效能——Admin 後台用 NestJS 開發速度快 3 倍，而且後台的流量不高，不需要 Go 的效能。
雙語言架構的 tradeoff：15+ 人的團隊本來就有分工，Go team 做核心路徑，Node team 做後台和膠水服務。
K8s 在這個規模值得：[[micro-service/41-docker-compose-vs-k8s|#41]] 的 1000 用戶門檻已經過了，自動擴縮和零停機部署開始有意義。ES + Kafka：[[micro-service/66-conclusion-storage|#66]] 的漸進式路線圖階段 4，5000 用戶的量足以支撐維護成本。
效能調校重點
- Tier 1-2 必須已經做完（這是基礎，不是選項）
- Go 服務間用 gRPC + Protobuf：+30% 序列化效能
- PG Read Replica：讀寫分離在這個規模開始有意義
- Redis Cluster：單一 Redis 的記憶體和連線數會成為瓶頸
- 監控：Grafana + Prometheus + ELK，沒有監控的微服務是災難
這個規模的真正挑戰
技術選型反而是最簡單的部分。真正的挑戰是服務邊界怎麼劃（[[micro-service/39-when-to-split|#39]]）、團隊分工、資料一致性、和分散式追蹤。
回到起點
第 1 篇說：「功能測試回答能不能動，壓力測試回答能撐多少人。」
68 篇文章後，我們知道了：
- 能撐多少人：看 [[micro-service/23-cross-layer-capacity|#23 容量規劃表]]
- 該先做什麼：看 [[micro-service/62-optimization-roadmap|#62 最佳化路線圖]]
- 每一層選什麼：看 [[micro-service/63-conclusion-f2e|#63]]~[[micro-service/67-conclusion-infra|#67]] 五層結論
- 最佳組合是什麼：就是本篇
第 30 篇說：「壓測的價值不是數字本身，是數字背後的判斷力。」
這 68 篇文章教會我們的也不是排名——是在面對「該用什麼」這個問題時，有數據支撐的判斷力。
Go 比 Django 快 5 倍，但如果你的團隊全是 Python 工程師，選 Go 只會讓你慢 5 倍。Svelte bundle 比 Angular 小 2.4 倍，但如果你的專案需要 Angular 的嚴格架構，小 bundle 救不了混亂的程式碼。
壓測教會我們的不是排名，是判斷力。
選技術的方法論在 [[micro-service/37-framework-selection-methodology|#37]]、選完之後的實作路線在 [[micro-service/40-microservice-split-patterns|#38]]。所有 42 項壓測數據就在這 68 篇裡，需要的時候回來查。
本系列文章
完整 68 篇目錄見 系列首頁
← 上一篇：Infra 結論：架構模式與部署策略最終推薦