為何越來越多團隊改用Quarkus？一篇技術長文的論點輪廓整理

一篇題為「為什麼越來越多人用Quarkus？」的技術文章於2026年10月15日發表在中國大陸開發者社區掘金，作者為「蘇三說技術」。文章從企業成本、啟動時間與記憶體佔用等角度，梳理Java技術體系在雲原生環境下的困境，並解釋Quarkus框架的設計差異。本臺依據該篇原文整理其論點輪廓與可核實資訊的邊界，文中的具體數字均屬作者自述或其引用的示例，未經獨立驗證。

文章緣起：一次內部技術棧「瘦身」評估

作者在文中交代，有同行所屬公司正在進行Java技術棧的瘦身評估，請其協助比較候選框架。該同行提出的背景是：公司內部運行兩百多個Spring Boot服務，每個服務平均佔用512MB記憶體，按Kubernetes節點規格折算，光是JVM堆記憶體的閒置浪費，一年就要多花數十萬元人民幣。此外，每次滾動發布時，數百個Pod同時重啟，僅等待服務啟動完成的環節，發布窗口就需預留半小時。

作者引述對方的說法稱，問題並非Spring Boot不好用，而是既有體系與雲原生環境出現結構性錯配。

三重困境：啟動、記憶體與預熱

文章將傳統Java應用在雲原生環境下的問題歸納為三項。第一是啟動時間，作者稱Spring Boot應用通常需要5至15秒完成上下文初始化，類載入、Bean實例化、依賴注入與自動配置掃描等工作在主執行緒上序列執行，且JIT編譯器尚未介入，解釋執行的開銷進一步放大延遲。

第二是記憶體佔用。作者以對照組舉例：一個最簡單的Spring Boot Web應用常駐記憶體常超過200MB，同等功能的Go應用可能僅需20MB。在Kubernetes集羣中，記憶體按副本數線性計費，每個副本多200MB，在百副本規模下每月即達數千美元的成本。

第三是預熱問題。JIT編譯器需數千次方法呼叫才能識別熱點並觸發編譯，應用在啟動後前幾分鐘的吞吐量可能僅為穩定期的30%至50%。對按需擴縮容的場景，新副本剛啟動就承接流量可能導致請求逾時。

作者認為，這些問題的根源不在Java語言本身，而在Java生態長期沿用的運行時反射模型。Spring、Hibernate、Jackson等主流框架都依賴反射在運行期掃描類路徑、解析註解與動態生成代理，這種模型在開發期靈活，運行期卻需付出代價。

Quarkus的解法：把工作前移到構建期

文章指出，Quarkus的核心設計是把重量級工作前移至構建階段。Spring Boot在啟動時執行掃描、解析、建構Bean定義、反射建立與注入的完整流程；Quarkus則將前幾步全部移到構建階段完成，運行時只載入預先生成的程式碼。作者稱這是啟動時間從5.6秒降至1.3秒的根本原因。

在依賴注入部分，文章比較Spring DI與Quarkus的ArC容器。ArC在構建期即掌握Bean之間的依賴關係，直接生成如 new GreetingService(new GreetingBean()) 形式的位元組碼，運行時無需反射查找建構子或動態生成代理，依賴注入從運行時操作變為編譯期生成的程式碼。

文中另提到，Quarkus 4以Java 21為基線，虛擬執行緒成為一等公民，開發者可透過 @RunOnVirtualThread 註解讓阻塞式API運行在虛擬執行緒上，兼顧簡單寫法與高並發能力。

可核實邊界

該文屬個人技術論述性質。文中「兩百多個服務、每個512MB、一年數十萬元」等具體數字來自作者轉述的個案，無法獨立查證；啟動時間與記憶體佔用的對比數據亦為作者給出的示例值，實際表現會因應用規模、組態與硬體環境而異。Spring Boot社羣本身亦有GraalVM原生映像與CRaC等對應方案，惟該文未就此多做比較。

截至目前，Quarkus與Spring Boot在企業界的實際採用比例仍以Spring系生態佔大宗，此點與該文「越來越多人用」的趨勢描述並不衝突，惟趨勢的具體規模缺乏公開量化數據支持。