Micro-framework 的優勢在起步
Micro-framework 的設計哲學是：只給必要的東西，其他你自己決定。
Express 給你路由和 middleware；Flask 給你路由和 context；Gin 給你路由和 binding。其他——ORM 怎麼選、validation 用哪個 library、folder structure 怎麼組織——全部是你的決定。
這在專案起步時非常好：
- 沒有 framework 強迫你用它的 ORM（你可以選任何一個）
- 沒有多餘的 overhead（只裝你真正需要的套件）
- 學習曲線低（核心概念少）
- Prototype 速度快
一個 2 人的 side project，用 Flask 寫一個 API 從零到第一個 endpoint 可能只要 30 分鐘。用 Spring Boot 可能要 1 小時光是設定。
Full-stack Framework 的優勢在規模
Full-stack framework（batteries-included）在專案規模變大之後開始展現優勢：
Convention 統一：Django 的 MVC 結構、Laravel 的 Service Provider pattern、Spring 的 Bean 管理，讓任何有框架經驗的工程師都知道「那種東西放在哪裡」。新人 onboarding 的第一週不用搞懂「這個專案的 folder structure 邏輯」。
Onboarding 成本可預期：「你懂 Django 嗎？懂的話一週可以上手」vs「你懂 Flask 嗎？懂，但這個專案的 Flask 結構是 Tom 自己設計的，要再看一週才能理解」。
生態整合已經做好：Django Admin、Laravel Horizon、Spring Security 不是「有人寫了一個套件」，而是「框架維護者保證和整個生態相容的官方整合」。第三方套件和官方套件的深度不一樣。
臨界點在哪裡
沒有一個精確的數字，但幾個觀察：
人數：當一個 codebase 有超過 5–8 個人同時在改，micro-framework 每個人寫法不一樣的問題就開始出現。超過 15 人的團隊，沒有強制架構 convention 的 micro-framework 系統幾乎必然變成 spaghetti。
年齡：系統跑了 3 年以上，原始開發者很可能已經不在了。新人要維護一個 micro-framework 系統，但沒有 convention 告訴他「為什麼這樣設計」，每次改都是猜測。Full-stack framework 的 convention 讓「這個 class 在哪裡、這個邏輯為什麼在這裡」有文件化的 convention 可以依循。
複雜度：系統涉及的業務流程超過 5–10 個核心領域，微服務拆分之前，DI / module 邊界管理開始變得重要。
遷移的可能性
Micro-framework → Full-stack framework 的遷移通常比想像中難。
不是技術困難，而是行為改變困難：你已經有一套「這個系統怎麼組織」的 mental model，換框架意味著要同時重寫 code 和重建 mental model，同時要保持業務繼續跑。
更可行的策略：
- 新模組用新框架：舊系統繼續用 Express，新功能以 NestJS microservice 的形式加進來
- 漸進遷移：在 Express 系統裡逐步引入 NestJS 的架構概念（DI、Service 層分離），讓結構越來越像 NestJS，等規模到了再正式遷移
- 直接重寫：業務邏輯已經穩定、技術債高到重寫比遷移便宜的時候
實用判斷流程
團隊 < 5 人，專案 < 1 年，快速驗證 MVP？
→ Micro-framework
團隊 5-15 人，需要可維護性但不想全部重來？
→ 在 micro-framework 上建立自己的 convention（參考 proto 結構）
團隊 > 15 人，系統 > 2 年，或工程師流動率高？
→ Full-stack framework（NestJS / Django / Spring Boot）
有明確的效能需求、不在乎架構 overhead？
→ Micro-framework + 自己的 convention，永遠可以
選型沒有對錯，只有「這個情境下哪個的 trade-off 更合理」。