把兩百多個元件踢出核心框架：Flutter 這場架構分家為何讓開發者吵起來

手機螢幕上滑過一張應用程式的介面截圖。平心而論，只看視覺呈現，多數人分不清這是用原生系統寫的，還是跨平臺框架畫出來的。過去幾年，Flutter 成功把「一套程式碼，跑遍兩個手機系統」的想像變成日常工作流程裡的標準配備。但在 2026 年 7 月，開發者論壇的風向突然變了。

一場名為「Flutter UI 解耦」的架構變革正式進入實質階段。官方套件庫裡悄悄上線了 material_ui 和 cupertino_ui 兩個獨立包。在掘金等技術社羣裡，這則貼文閱讀量迅速破萬，留言區擠滿了正在加班改程式碼的工程師。有人抱怨這是在折騰底層邏輯，也有人認為這是框架走向成熟的必經陣痛。

這場討論帶出了一個有趣的技術文化現象：跨平臺開發工具的演化史，幾乎就是一部不斷在「大一統」與「模組化」之間來回擺盪的歷史。

合久必分的時間軸：從一個合理的決定說起

要把這場分家看清楚，得把時間推回 Flutter 還沒正式發表的日子。

2015 年，這個專案還有一個代號叫 Sky。當時 Google 在前一年剛發布全新的介面設計語言 Material Design，亟需一個載體來展示這套視覺標準的跨平臺潛力。到了 2017 年 5 月的 Google I/O 開發者大會，Flutter 第一個 alpha 版本亮相。

為了讓開發者快速上手，官方團隊做了一個在當時看來極度合理的決定：把 Material Design 的全部介面元件，直接內建在 Flutter 的核心包裡。開發者只要寫一行導入指令，就能呼叫出選單、按鈕、對話框等全套現成元件。

降低入門門檻與統一設計語言，成了前五年的黃金法則。2018 年 Flutter 1.0 正式發布時，蘋果 iOS 風格的介面庫也以同等地位被塞進了核心框架。從此，無論是 Android 的 Material 還是蘋果的 Cupertino，兩大陣營的視覺規範在 Flutter 內部共享同一套主題傳遞機制。

Flutter 聯合創始人 Ian Hickson 曾用一句話總結這個階段的策略：「我們為了開發者體驗，犧牲了架構的純淨性。」

這筆交易在前幾年穩賺不賠。但隨著時間推移，框架本身承載的期待越來越大，這套將所有東西綁在一起的做法，開始讓系統顯得臃腫。到了 2025 年，官方正式宣布 UI 解耦路線圖。2026 年 7 月，兩個獨立包上架，分家進入實質階段。

程式碼裡的空間爭奪戰

到底「緊耦合」意味著什麼？用檔案數量來解釋或許最直接。

根據開發者對舊框架原始碼的統計，包含核心渲染邏輯的底層目錄有大約一百八十多個檔案，而 Material 介面庫佔了一百八十四個檔案，iOS 風格的 Cupertino 也有五十二個檔案。這意味著，介面元件的程式碼數量幾乎與底層引擎一樣龐大。

過去，只要你想用 Flutter 畫出一個最簡單的按鈕，你的專案就必須把包含一百八十多個元件的整套 Material 設計邏輯全部載入。這就像是去超商買一瓶礦泉水，店員卻堅持你要把整座倉庫的貨架都扛回家。

將介面元件庫拆分出去後，底層框架終於可以「減重」。新的獨立包讓開發者可以根據專案需求，選擇只載入需要的介面系統，甚至完全使用自行設計的視覺風格，不再被框架預設的兩大巨頭綁架。

這與我們先前觀察過的 當手機背蓋被罵成垃圾材質，玻纖到底踩了數位圈的哪條底線 中的消費者焦慮有異曲同工之妙。硬體玩家在乎的是材質與實用性的平衡，而軟體開發者在乎的是框架的純淨度與載入效率。當工具不再強迫使用者全盤接受，把選擇權交還給第一線人員，往往是一場艱難但必要的拆解。

痛點與陣痛：開發者正面迎戰重構潮

理想狀態下，架構解耦是一件好事，但實際落地時，首當其衝的是升級與維護成本。

「以前只要等 Flutter 官方發大版本，所有介面元件的更新都會跟著一起來。現在不同了。」一位長期關注跨平臺技術的開發者在掘金的留言區寫道。拆分之後，底層引擎與介面元件的更新週期正式脫鉤。

這帶來了幾個社羣熱議的實際痛點：

• 版本相容性追蹤：過去介面與引擎綁在一起，出錯只要查一個版號。現在開發者必須自行確認手中的 material_ui 版本，是否能完美匹配最新下載的 Flutter 核心引擎。
• 舊專案遷移成本：對於已經運作多年的大型商業應用來說，全面替換導入路徑是一項浩大工程。官方雖然提供了過渡期的相容方案，但技術債的累積仍不可避免。
• 學習曲線的微調：對於剛入門的新手，過去那種「一行指令拿到全部能力」的順暢感消失了。初學者現在必須先理解什麼是核心引擎，什麼是外加的介面套件。

一場遲到七年的系統瘦身

把時間軸拉長來看，這場架構重整其實是當代軟體工程流行病的一種縮影。

近年來，從前端網頁到後端伺服器，整個科技圈都在瘋狂推崇微服務與模組化。大型單體架構被視為難以維護的恐龍。Flutter 這次將最龐大的兩個介面庫剝離，本質上就是一次單體架構的微服務化。

系統設計往往面臨兩種極端的拉扯。一端是「開箱即用的全家桶」，主打降低門檻，吸引大量早期使用者；另一端是「自由組裝的積木盒」，強調輕量化與客製化，通常是成熟期產品的選擇。

回顧科技論壇上的其他爭論，這種對系統資源與架構純淨度的執著屢見不鮮。正如先前引發熱議的 跳過開機畫面直接把企鵝放進口袋：那百分之十的桌面份額與百萬玩家的作業系統遷徙 一般，作業系統板塊的位移從來不只是技術數字的較量，更是使用者對於底層控制權與輕量化追求的具體展現。

對於開發者而言，框架的演進就像是城市基礎建設的翻新。一開始為了快速發展，所有管線都埋在同一條溝渠裡。當城市規模擴張到一定程度，污水、電力、電信線路終究要分門別類，放進各自的管道。

解耦之後，Flutter 不再只是一個綁定特定設計語言的框架。它變成了一個更純粹的渲染引擎與底層工具。這意味著，如果明天有設計師提出了一套全新的、不屬於蘋果也不屬於 Google 的介面語言，開發者也能輕易地用 Flutter 把它畫出來。

天下大勢，合久必分，分久必合。或許再過幾年，當輕量化帶來的陣痛被新一代開發者習慣後，又會有某個主打「ALL-IN-ONE」的新框架橫空出世，再次席捲開發者社羣。但在這個 2026 年的夏天，工程師們只能先泡杯咖啡，打開編輯器，開始手動替換那幾百行程式碼裡的老舊導入路徑。