結論先講
壓測最有價值的產出不是數字，是判斷力。 蓋完平台、跑完 42 項測試、寫完 30 篇文章之後，我做技術決策的方式徹底改變了。不是因為記住了「Go 74 RPS、Spring Boot 228 RPS」這些數字，而是因為學會了「先測再決定」「免費午餐先吃」「不要被排名騙」這些思維方式。
五個改變我做決策方式的 Insight
1. 免費午餐比換框架效果大
這是整個系列最重要的一句話。
Redis cache + nginx keepalive + multi-worker，三個配置層面的改動，組合起來 13 倍提升（第 21 篇）。同時期「從 Django 換成 Go」的提升大概 4-5 倍。
先把免費午餐吃完，再考慮換框架。 大部分團隊的效能問題不是選錯框架，而是沒做這三件事。
如果重來一次，我會在動任何架構之前，先確認：
- Redis cache 開了嗎？
- nginx keepalive 開了嗎？
- 多 worker 模式開了嗎？
- DB 連線池調過了嗎？
2. UV 10 就能暴露問題
不需要等到「百萬用戶」才做壓測。UV 10 就能告訴你系統有沒有結構性問題（第 28 篇）。
Django 在 2 CPU 上 UV 10 就開始出問題。不是 Django 的 bug，是 gunicorn + bcrypt 在 2 CPU 上的結構性限制。給 4 CPU 就沒問題了。
如果重來一次，我會在第一天就跑一次 UV 10 的壓測。不用花很多時間——一個簡單的 k6 腳本 5 分鐘就寫好（第 4 篇）。
3. 場景不同，排名不同
Go 在 CRUD 場景排第一（第 9 篇），Spring Boot 在混合場景排第一（第 24 篇），兩者在檔案上傳場景並列第一（第 25 篇）。
沒有「最好的框架」，只有「最適合你場景的框架」。
如果重來一次，我會先定義「我的應用長什麼樣」（讀多？寫多？有 Auth？有檔案上傳？），然後找最接近的壓測場景看排名。而不是看一個 Hello World benchmark 就下結論。
4. 選框架先問三個問題
效能排名只是參考。真正影響決策的三個問題（第 23 篇）：
- 團隊會什麼語言？（招得到人嗎？學習成本多高？）
- 硬體預算多少 CPU？（Django 2 CPU 撐 50 人，4 CPU 撐 200 人）
- 需要什麼生態？（Python ML / Java 企業 / JS 全端）
如果重來一次，我會先回答這三個問題，再去看壓測數字。不是反過來。
5. 不要急著拆微服務
第 28 篇 講了我們為什麼拆。但如果重來一次，我會先做完免費午餐，看看是不是能把單體撐到 UV 100-500。
拆微服務的成本：
- Event-driven architecture 的設計和實作
- 跨服務 transaction 的處理
- 監控和 log 的複雜度（GitLab + Grafana + Portainer）
- 每個 service 的個別調校
這些成本在 UV 100 以下很可能不值得。
拆微服務的正確時機不是「學到了就要用」，而是「單體 + 免費午餐已經撐不住了」。
最意外的五個發現
| 發現 | 篇章 | 為什麼意外 |
|---|---|---|
| Django/FastAPI UV 10 就能壞 | [[micro-service/09-crud-overview|#9]] | 以為至少 100 才會出問題 |
| Spring Boot 從倒數第二變第一 | [[micro-service/24-mixed-overview|#24]] | CRUD benchmark 騙了所有人 |
| ORM vs Raw SQL 只差 10% | [[micro-service/18-db-bulk-and-index|#18]] | 以為至少差 50% |
| Bulk Insert 差 26 倍 | [[micro-service/18-db-bulk-and-index|#18]] | 比選 ORM 影響大得多 |
| 前端框架差距只有 6 分 | [[micro-service/15-f2e-lighthouse-ranking|#15]] | 以為 Svelte 會贏很多 |
給正在考慮微服務的人
先做的事（成本低、效果大）
- 跑一次 UV 10 的壓測（5 分鐘）
- 開 Redis cache（讀多場景 +6.5 倍）
- 開 nginx keepalive（一行配置 +7%）
- 開多 worker（一行配置 +93%）
- 調 DB 連線池（pool=50 高壓下 +70%）
再考慮的事（成本高、效果看場景）
- 拆微服務（需要 event-driven + 跨服務 transaction）
- 換框架（確認場景和壓測排名吻合）
- 換 DB（PG vs MySQL 看讀寫比）
- 上 K8s（1000 人以內 Docker Compose 就夠了，第 22 篇）
不要做的事
- 不要看 Hello World benchmark 選框架
- 不要加 cache 但不知道瓶頸在哪
- 不要把 Kafka 當 REST API 用（第 29 篇）
- 不要為了 Lighthouse 6 分的差距換前端框架
- 不要在 UV 100 以下急著拆微服務
這個系列的完整地圖
30 篇走完，回到 第 1 篇 的起點——「功能測試回答『能不能動』，壓力測試回答『能撐多少人』」。
現在你有了完整的答案：
- 前端（[[micro-service/15-f2e-lighthouse-ranking|#15-16]]）：差距 6 分，看生態不看分數
- 後端（[[micro-service/09-crud-overview|#9-14]], [[micro-service/24-mixed-overview|#24-27]]）：Go 最穩、Spring Boot 讀取最強、Express-TS 是安全牌
- DB（[[micro-service/17-db-pg-vs-mysql|#17-19]]）：PG 通用、MySQL 寫入、Bulk 比 ORM 影響大
- Storage（[[micro-service/20-storage-redis-es|#20]]）：PG + Redis 夠用，需要再加
- Infra（[[micro-service/21-infra-free-lunch|#21-22]]）：免費午餐先吃、水平擴展要算 DB 連線
- 容量規劃（[[micro-service/23-cross-layer-capacity|#23]]）：10 人到 5000 人的完整選型表
- 微服務（[[micro-service/28-monolith-to-microservice|#28-29]]）：遲早要做，但不要急
感謝你讀到這裡。
下一篇
PostgreSQL vs MySQL 完整選型 — 主系列到此結束。接下來是延伸系列——把壓測中發現的每個重要議題拉出來深入討論，從 DB 選型開始。
本系列文章
完整 68 篇目錄見 系列首頁
← 上一篇：企業裡的微服務現實：Cache 硬撐、Kafka 當 REST 用 → 下一篇：PostgreSQL vs MySQL 完整選型：不只是效能，是生態和未來