哈嘍，我是老劉

國慶前發了篇文章，主要講AI協同時代下，Flutter項目的狀態管理該如何進行技術選型。

文章鏈接：2025年Flutter狀態管理新趨勢：AI友好度成為技術選型第一標準

文章發出來後，很多GetX的擁躉在留言區質疑："老劉，你憑啥沒提GetX？"

還有朋友在微信裏私聊我。

看來這個話題確實戳中了很多人的神經。

今天就專門聊聊GetX這個事兒，説説為啥老劉從來沒有推薦過GetX。

如果你也是GetX的忠實用户，先別急着關閉頁面。

這篇文章可能會顛覆你的一些認知。

GetX很好，但是大而全的框架不一定適合你

先説明白一點：GetX確實是個好框架。

11k的GitHub星標不是白來的，它確實解決了很多Flutter開發中的痛點。

狀態管理、路由管理、依賴注入、國際化、主題切換...

GetX幾乎把Flutter開發中能遇到的問題都給你解決了。

這就像一個超級工具箱，什麼工具都有，拿來就能用。

但問題恰恰就出在這個"大而全"上。

第一個問題：能力圈陷阱

很多人説GetX簡單，上手快。

確實，寫個簡單的Demo，GetX幾行代碼就搞定了。

但這種"簡單"是有代價的。

你以為你學會了Flutter狀態管理，其實你只是學會了GetX的語法糖。

當你遇到複雜的狀態管理場景時，你會發現自己對Flutter的原生機制一無所知。

老劉自己面試過很多這樣的開發者：

用了一年Flutter，連StatefulWidget的生命週期都説不清楚。

更別提Provider、InheritedWidget這些Flutter的核心概念了。

這就像學開車只會開自動擋，遇到手動擋就抓瞎。

短期看起來效率很高，長期來看是在透支自己的技術能力。

而且真的拋開這些框架，用Flutter原生的功能去搭建一個簡單的App真的就會複雜很多嗎？

其實不是的。

Flutter本身已經有一套非常優雅的開發理念：

萬物皆組件，界面即函數
Everything is a Widget, UI = f(state)

具體來説就是："聲明式UI + 響應式編程 + 組件化架構"

只要掌握並遵循這個核心原則，基本上可以搞定90%以上的功能開發。

這也是為什麼老劉在路由管理、組件化、數據流等等方面一直推薦大型項目自己封裝的原因。

第二個問題：技術綁架

全家桶"式設計的另一個問題是。

一旦你開始用，你會發現很難只用其中一部分。

狀態管理用了GetX，路由自然也想用GetX。

路由用了GetX，依賴注入也順便用GetX。

最後整個項目都被GetX綁架了。

想要局部替換？比重構還難。

我去年接手過一個客户的諮詢項目，團隊想把GetX的路由部分替換成自己的路由管理方案。

結果發現GetX的狀態管理、依賴注入、路由管理之間耦合得太緊密。

牽一髮而動全身。

這種技術綁架是非常危險的。

技術選型應該是可插拔的，而不是一錘子買賣。

第三個問題：大型項目的精細化技術選型

大型項目需要的是精細化的技術選型。

狀態管理可能需要Bloc的嚴格架構約束。

路由管理可能需要Go Router的類型安全。

依賴注入可能需要Get_it的輕量級方案。

要知道在每一個細分的方向上，都會有很多專注且做到極致的技術方案。

比如RIverpod，就利用註解和代碼生成把狀態管理中最常用的模式都用最簡化的方式實現了。

能夠管理大型項目的技術負責人，一個核心能力就是把項目做精確的拆分然後做合理的技術選型。

所以如果你的項目只有10個頁面，“一站式”的技術選型當然沒有任何問題。

但是如果你的項目至少有幾十個頁面，項目負責人仍然上來就用了“一站式”的技術選型，那麼大概率他是在做"技術債務"。

真實案例

比如老劉去年去做TDD諮詢的一個項目。

項目開始就選擇了GetX，但是由於是歐洲客户，客户那邊需要單元測試覆蓋。

團隊後來希望通過TDD的方式，逐步完善項目的測試覆蓋率。

但是由於GetX對單元測試並不友好，導致團隊在推進TDD的過程中遇到了很多困難。

老劉當時做諮詢的過程中也是深度閲讀了Getx的源碼，幫客户找一個合適的解決方案。

所以之前那篇文章評論區裏説因為老劉不懂Getx所以才不推薦的，其實我是因為踩過坑。

老劉的項目進行狀態管理選擇是如何思考的

説了這麼多問題，那到底該怎麼選擇狀態管理方案呢？

老劉總結了自己在進行技術方案選型時遵循的四個原則：

第一：追求簡潔和強大的平衡

好的技術方案不是最簡單的，也不是最複雜的。

而是在日常開發的簡潔性和功能的強大性之間找到最佳平衡點。

真正好的狀態管理方案，應該是：

簡單場景用起來簡單，複雜場景也能hold住。

比如Riverpod，簡單的狀態管理就是一個Provider。

複雜的異步狀態管理，也有AsyncNotifier、StateNotifier等完整的解決方案。

這就像一把好刀，切菜很順手，切肉也不費勁。

而不是"瑞士軍刀"，什麼都能幹，但什麼都不精。

第二：優先考慮把一件事做到極致的框架

老劉有個技術選型的原則：

寧要專精的工具，不要萬能的玩具。

最好的方案往往是那些專門解決某一個問題的框架。

比如Bloc，就是專門為狀態管理而生的。

它的設計理念非常純粹：Event -> State。

所有的狀態變化都通過事件驅動，狀態流轉清晰可控。

雖然學習曲線稍微陡峭一點，但是一旦掌握，你會發現它在複雜業務場景下的表現力是非常好的。

再比如Provider，雖然功能相對簡單。

與Flutter的生命週期結合得天衣無縫。

這就是專精的力量。

第三：TDD友好性是必要因素

在老劉這邊的項目團隊，測試驅動開發（TDD）是必選項。

特別是在大型項目中，沒有完善的測試覆蓋，項目遲早會崩盤。

所以在選擇狀態管理方案時，一定要考慮它的測試友好性。

Bloc和RIverpod在這方面都做得非常好。

每個Bloc都可以獨立測試，狀態變化可以精確驗證。

反之，全局狀態、隱式依賴、私有生命週期管理，這些都會讓單元測試變得複雜。

第四：AI友好度是新的必要因素

這是2024年以後技術選型的新標準。

隨着AI編程工具的普及，代碼的AI友好度變得越來越重要。

什麼是AI友好度？

簡單説就是：AI能不能理解你的代碼，能不能幫你寫出正確的代碼。

在這方面，遵循標準模式的框架明顯更有優勢。

比如Bloc的Event-State模式，這是一個非常經典的設計模式。

AI對這種模式的理解度很高，生成的代碼質量也更好。

而有很多"黑魔法"的框架，AI就很難理解。

而且這個差距在未來只會越來越大。

因為AI訓練數據中，標準模式的代碼佔絕大多數。

所以從長遠來看，選擇AI友好的技術方案，就是在為未來的開發效率投資。

GetX爭議背後的深層思考：什麼才是好的技術選型？

説了這麼多，其實GetX爭議背後反映的是整個行業的一個深層問題。

我們太容易被"短期效率"迷惑，而忽視了"長期價值"。

這就像投資一樣。

追漲殺跌的人，看起來每天都在賺錢。

但真正的投資高手，都在做時間的朋友。

技術選型也是一樣的道理。

好的技術選型不是選最熱門的，而是選最適合的。

不是選最簡單的，而是選最可持續的。

老劉總結的技術選型四大標準：

1. 簡潔與強大的平衡 - 既要好用，也要夠用

2. 專注度 - 寧要專精的工具，不要萬能的玩具

3. 測試友好性 - 沒有測試的代碼，就是技術債務

4. AI友好度 - 面向未來的開發效率投資

這四個標準，不僅適用於狀態管理的選擇。

也適用於所有的技術選型決策。

最後送給大家一句話：

"在技術的世界裏，沒有銀彈，只有權衡。"

真正的技術成長，往往發生在那些"看起來更難"的選擇裏。

因為只有走出舒適圈，你才能看到更大的世界。

這裏多説一句，老劉這邊的項目通常是考慮團隊開發，項目規模相對較大的場景，所以技術選型也是基於這個基礎做出的。

對於獨立開發者和小型項目來説，“一站式”方案並沒有什麼問題，反而可能是最優解。

好了，你的項目中，還有哪些"看似便利，實則陷阱"的技術選擇？

歡迎在評論區分享你的踩坑經歷。

如果看到這裏的同學對客户端開發或者Flutter開發感興趣，歡迎聯繫老劉，我們互相學習。
點擊免費領老劉整理的《Flutter開發手冊》，覆蓋90%應用開發場景。
可以作為Flutter學習的知識地圖。

覆蓋90%開發場景的《Flutter開發手冊》