1. 為什么 Flutter 開發(fā)者遲早要面對狀態(tài)管理先聊聊狀態(tài)管理這個(gè)問題為什么在 Flutter 里如此討人嫌。不管你是剛看完 Flutter 官方文檔準(zhǔn)備寫第一個(gè) Demo還是已經(jīng)做過幾個(gè)商用 App都繞不開一個(gè)靈魂拷問頁面之間共享的數(shù)據(jù)到底用什么方案來管我用 Flutter 做開發(fā)的時(shí)間不算短從早期的StatefulWidget一把梭到后來在項(xiàng)目里同時(shí)引入 Provider 和 GetX再到團(tuán)隊(duì)里推行 Bloc可以說這三座大山都爬過一遍。先說一個(gè)比較容易讓人困惑的點(diǎn)Flutter 本身不限制你怎么管理狀態(tài)。它只提供了StatefulWidget和setState這種最基礎(chǔ)的 UI 刷新機(jī)制但真實(shí)項(xiàng)目里你根本不可能靠setState撐起全局登錄態(tài)、購物車、用戶偏好設(shè)置這些跨頁面共享的數(shù)據(jù)。所以社區(qū)里才陸續(xù)出現(xiàn)了 Provider、Bloc、GetX 這些解決方案。這篇內(nèi)容主要解決三個(gè)問題第一這三種方案各自的核心原理和適用場景是什么第二對于一個(gè)真實(shí)項(xiàng)目來說選型時(shí)到底該看哪些維度第三實(shí)際開發(fā)中有哪些坑是官方文檔里不會(huì)明說的。適合正在學(xué)習(xí) Flutter 狀態(tài)管理的初學(xué)者也適合已經(jīng)在項(xiàng)目里用了某個(gè)方案、但想橫向評估是否要遷移的團(tuán)隊(duì)。2. Provider官方路線下的輕量首選2.1 它的本質(zhì)就是 InheritedWidget 的優(yōu)雅封裝很多教程會(huì)把 Provider 講得像一個(gè)魔法盒子其實(shí)它做的事非常簡單把數(shù)據(jù)放到組件樹上層的 Provider 里下層任何組件通過context.watchT()或context.readT()取用數(shù)據(jù)變化時(shí)自動(dòng)重建對應(yīng)的 UI。理解這一點(diǎn)對后續(xù)排查 bug 特別重要。因?yàn)?Provider 底層就是 Flutter 自帶的InheritedWidget它天生具備“從根節(jié)點(diǎn)向下傳遞數(shù)據(jù)”的能力。但I(xiàn)nheritedWidget用起來很繁瑣你要手寫updateShouldNotify、手動(dòng)管理依賴關(guān)系、還要小心處理 dispose。Provider 把這些臟活都收走了你用幾行代碼就能聲明一個(gè)全局可訪問的數(shù)據(jù)源。一個(gè)經(jīng)典的計(jì)數(shù)器示例長這樣// 1. 定義狀態(tài)類繼承 ChangeNotifier class CounterModel extends ChangeNotifier { int _count 0; int get count _count; void increment() { _count; notifyListeners(); // 關(guān)鍵通知所有監(jiān)聽者刷新 } } // 2. 在組件樹頂層注冊 void main() { runApp( ChangeNotifierProvider( create: (_) CounterModel(), child: MyApp(), ), ); } // 3. 在任意子組件中讀取 class CounterPage extends StatelessWidget { override Widget build(BuildContext context) { // watch 表示依賴這個(gè)數(shù)據(jù)變化時(shí)重建當(dāng)前組件 final counter context.watchCounterModel(); return Scaffold( body: Center(child: Text(${counter.count})), floatingActionButton: FloatingActionButton( // read 表示只讀取一次不建立依賴 onPressed: () context.readCounterModel().increment(), child: Icon(Icons.add), ), ); } }看到?jīng)]核心就三句話定義數(shù)據(jù)模型、注冊 Provider、在組件里 watch/read。這也是為什么官方文檔把 Provider 列為推薦方案之一——它學(xué)習(xí)曲線平緩、代碼侵入性低、調(diào)試方式直觀因?yàn)槟汶S時(shí)能用 Flutter Inspector 查看組件樹上的 Provider 節(jié)點(diǎn)。2.2 watch、read、select 三個(gè)方法必須分清Provider 里最容易踩的坑就是搞混watch和read的使用時(shí)機(jī)。watch會(huì)讓當(dāng)前組件與數(shù)據(jù)源建立依賴關(guān)系數(shù)據(jù)一變就重建組件read只負(fù)責(zé)獲取數(shù)據(jù)對象不建立依賴。如果該用read的地方用了watch會(huì)出現(xiàn)性能問題——比如一個(gè)從不需要響應(yīng)變化的按鈕也會(huì)跟著數(shù)據(jù)一起重建。反過來該用watch的地方用了readUI 就不刷新了。還要記住一個(gè)進(jìn)階用法context.selectT, R(R Function(T value) selector)。它的意義在于只針對你關(guān)心的部分建立依賴。舉個(gè)例子如果UserModel里既有用戶名又有頭像 URL但某個(gè)組件只顯示用戶名用select后頭像變了就不會(huì)觸發(fā)這個(gè)組件重建。這在數(shù)據(jù)模型比較復(fù)雜的場景下能明顯減少不必要的 build。注意watch和read的使用位置有講究。按 Flutter 官方 lint 規(guī)則watch只能寫在build方法里read可以寫在事件回調(diào)中。如果你在onPressed里寫context.watchCounterModel()會(huì)直接觸發(fā) lint 警告而且這種寫法本身就代表邏輯錯(cuò)誤。另外補(bǔ)充一個(gè)我在實(shí)際項(xiàng)目里用到的小技巧當(dāng)你的狀態(tài)類里有多個(gè)不相關(guān)的字段時(shí)不要頻繁地notifyListeners()。正確的做法是拆分成多個(gè) ChangeNotifier比如CartModel管購物車、UserModel管用戶信息讓每個(gè)數(shù)據(jù)源各司其職。一個(gè) ChangeNotifier 里塞了十幾個(gè)字段任何字段一變就全量通知性能會(huì)逐漸劣化而且排查問題的時(shí)候你會(huì)瘋掉。2.3 Provider 適合什么項(xiàng)目純從技術(shù)選型角度說Provider 特別適合這幾類場景中小型項(xiàng)目、團(tuán)隊(duì)里新手比較多、項(xiàng)目已經(jīng)有了一定的頁面結(jié)構(gòu)但不想做大規(guī)模改造。它不像 Bloc 那套要求你嚴(yán)格分層也不像 GetX 那樣把所有功能揉在一起屬于那種“你可以在一個(gè)小時(shí)內(nèi)把它用起來也不會(huì)在未來造成太大維護(hù)負(fù)擔(dān)”的庫。但如果你的項(xiàng)目特別大、頁面層級很深、團(tuán)隊(duì)對狀態(tài)管理的規(guī)范性要求極高Provider 這種偏“自由發(fā)揮”的方案就需要靠團(tuán)隊(duì)約定來約束。否則每個(gè)人各自建 Provider、到處亂放MultiProvider同樣會(huì)亂成一鍋粥。Provider 不是不能讓代碼變得清晰而是它不做強(qiáng)制約束最終質(zhì)量取決于團(tuán)隊(duì)紀(jì)律。3. Bloc用事件驅(qū)動(dòng)撐起大型項(xiàng)目的確定性3.1 事件與狀態(tài)分離的核心思想如果你去翻 Bloc 的官方文檔會(huì)發(fā)現(xiàn)他們反復(fù)強(qiáng)調(diào)一個(gè)概念UI 只負(fù)責(zé)把事件Event發(fā)出去Bloc 內(nèi)部接收事件、執(zhí)行邏輯然后輸出新狀態(tài)StateUI 根據(jù)狀態(tài)來渲染。這種設(shè)計(jì)最直接的好處是單向數(shù)據(jù)流。UI 不會(huì)直接去修改數(shù)據(jù)而是“告訴”邏輯層發(fā)生了什么邏輯層再?zèng)Q定狀態(tài)怎么變。這樣整個(gè)數(shù)據(jù)流動(dòng)的方向非常清晰Event - Bloc - State - UI - Event形成閉環(huán)。在大型團(tuán)隊(duì)里這種清晰度非常值錢——新人看代碼的時(shí)候不需要猜測數(shù)據(jù)從哪里來、被誰改過沿著事件流找就行。我用 Cubit 來寫一個(gè)計(jì)數(shù)器示例因?yàn)?Cubit 比完整的 Bloc 更輕量// Cubit 是 Bloc 的簡化版本不需要定義 Event 類 class CounterCubit extends Cubitint { CounterCubit() : super(0); void increment() emit(state 1); } // 在 UI 中使用 class CounterPage extends StatelessWidget { override Widget build(BuildContext context) { return BlocProvider( create: (_) CounterCubit(), child: BlocBuilderCounterCubit, int( builder: (context, count) { return Scaffold( body: Center(child: Text($count)), floatingActionButton: FloatingActionButton( onPressed: () context.readCounterCubit().increment(), child: Icon(Icons.add), ), ); }, ), ); } }但如果業(yè)務(wù)邏輯更復(fù)雜比如“從服務(wù)器拉取數(shù)據(jù)有加載中、成功、失敗三種狀態(tài)”就推薦用完整的 Bloc 方案把事件也定義成類// 定義事件 sealed class CounterEvent {} class CounterIncrementRequested extends CounterEvent {} // 定義狀態(tài) class CounterState { final int count; const CounterState(this.count); } // Bloc 核心邏輯 class CounterBloc extends BlocCounterEvent, CounterState { CounterBloc() : super(const CounterState(0)) { onCounterIncrementRequested((event, emit) { emit(CounterState(state.count 1)); }); } }這樣寫的優(yōu)勢在于事件本身成為了一種文檔。你只需要瀏覽 Event 類列表就能大概了解這個(gè)模塊支持哪些操作狀態(tài)類列表則說明了頁面會(huì)有哪些展示形態(tài)。這種“自文檔化”的效果在長期維護(hù)中特別有價(jià)值。3.2 別把 Stream 當(dāng)成洪水猛獸Bloc 的底子是 Dart 的 Stream。很多初學(xué)者一聽到“流式編程”就打退堂鼓其實(shí)完全沒必要。在 Bloc 的封裝下絕大多數(shù)時(shí)候你接觸不到 Stream 的細(xì)節(jié)你只需要用BlocProvider注冊、用BlocBuilder監(jiān)聽狀態(tài)變化、用context.read發(fā)送事件剩下的流式轉(zhuǎn)換 Bloc 框架已經(jīng)替你處理好了。但理解 Stream 至少有一個(gè)好處你能理解 BlocBuilder 為什么會(huì)重復(fù)執(zhí)行、為什么狀態(tài)變化需要“不可變數(shù)據(jù)”來觸發(fā)識別。Dart 的 Stream 在比較時(shí)遵循運(yùn)算符如果兩個(gè) State 引用相等Bloc 內(nèi)部就不會(huì)通知 UI 更新。所以如果你在 emit 的時(shí)候返回了同一個(gè)對象比如給同一個(gè) List 直接 add而不是創(chuàng)建一個(gè)新 ListUI 是不會(huì)刷新的。這是用 Bloc 時(shí)最容易踩的暗坑。正確做法是每次狀態(tài)變化都生成新的對象class CartState { final ListCartItem items; const CartState(this.items); // 每次添加商品都返回一個(gè)新狀態(tài) CartState copyWithNewItem(CartItem item) { return CartState([...items, item]); } }3.3 測試友好是 Bloc 最大的隱藏優(yōu)點(diǎn)很多團(tuán)隊(duì)選 Bloc 并不是因?yàn)?UI 寫起來舒服而是因?yàn)锽loc 太好測了。它把純邏輯從 UI 里完全剝離出來你不需要啟動(dòng) Flutter 引擎不需要模擬點(diǎn)擊直接blocTest就能驗(yàn)證邏輯正確性blocTestCounterBloc, CounterState( increment 后 count 加 1, build: () CounterBloc(), act: (bloc) bloc.add(CounterIncrementRequested()), expect: () [const CounterState(1)], );這種測試方式速度極快、穩(wěn)定性極高。我在做支付流程這種對正確性要求極高的模塊時(shí)Bloc 的價(jià)值體現(xiàn)得尤其明顯。你可以把每種業(yè)務(wù)分支都寫成測試用例CI 里跑一遍比任何人工測試都可靠。注意用 Bloc 時(shí)要警惕“為了 Bloc 而 Bloc”。如果只是一個(gè)計(jì)數(shù)器、一個(gè)開關(guān)狀態(tài)、一個(gè)下拉刷新完全不需要引入 Event/State 的復(fù)雜定義徒增代碼量。Bloc 適合的是邏輯有明確“狀態(tài)機(jī)”特征的模塊登錄流程、訂單流程、多媒體播放控制等。4. GetX效率無敵但爭議不斷的全能選手4.1 三個(gè)核心功能一網(wǎng)打盡GetX 和 Provider、Bloc 最大的不同在于它根本不只是一個(gè)狀態(tài)管理庫而是一套“全家桶”狀態(tài)管理、依賴注入、路由管理、國際化、主題切換全給你包圓了。也就是說你用 GetX 之后很多第三方庫都可以不引了一個(gè)框架從頁面跳轉(zhuǎn)到狀態(tài)管理全部搞定。狀態(tài)管理部分它提供了兩套模式。一套是響應(yīng)式模式// 創(chuàng)建響應(yīng)式變量 var count 0.obs; // 在 UI 中監(jiān)聽 Obx(() Text(${controller.count}));另一套是類似 Provider 的 Builder 模式GetBuilderCounterController( builder: (controller) { return Text(${controller.count}); }, );依賴注入也做得很舒服Get.put(CounterController()); // 全局注入 Get.lazyPut(() CounterController()); // 懶加載 Get.findCounterController(); // 從任意位置獲取 // 頁面銷毀時(shí)自動(dòng)釋放 Get.deleteCounterController();路由更是簡單到任性Get.to(NextPage()); Get.back(); Get.offAll(LoginPage());這套組合拳對開發(fā)效率的提升立竿見影。我見過不少獨(dú)立開發(fā)者用 GetX 三五個(gè)晚上就能出一個(gè) App 初版這正是它的核心優(yōu)勢——開發(fā)者只需要關(guān)心業(yè)務(wù)本身不需要把心智花費(fèi)在“先學(xué)一種狀態(tài)管理模式”上。4.2 GetX 讓人糾結(jié)的幾個(gè)問題不可否認(rèn)GetX 在社區(qū)里的口碑非常兩極分化。支持者覺得它是效率神器反對者則列出一堆問題。我以自己實(shí)際使用的經(jīng)驗(yàn)說說值得關(guān)注的幾點(diǎn)。第一是隱式依賴導(dǎo)致排查困難。Get.put之后你可以在任意地方Get.find看起來很爽但項(xiàng)目大了之后“這個(gè)對象是誰在什么時(shí)候創(chuàng)建的、什么時(shí)候銷毀的”變得很難追蹤。對比 Bloc 那種 Provider 層層包裹的顯式依賴關(guān)系GetX 更像“全局變量隨手用”方便是方便紀(jì)律性差的人會(huì)寫出嚴(yán)重耦合的代碼。第二是包體積問題。GetX 把路由、狀態(tài)管理、國際化等各種模塊打包在一起比單獨(dú)用 Provider 或 Bloc 會(huì)重不少。如果你是一個(gè)對包體積敏感、只想要狀態(tài)管理一個(gè)功能的小項(xiàng)目引入 GetX 有點(diǎn)殺雞用牛刀。而且它的 API 語法比較自成一派團(tuán)隊(duì)的代碼整體風(fēng)格會(huì)出現(xiàn)明顯的“GetX 味道”。第三是和小工具鏈的兼容性。GetX 自己的路由體系與 Navigator 2.0 之間的差異、它內(nèi)部對BuildContext的自動(dòng)管理方式在遇到某些需要精確控制的場景時(shí)會(huì)造成不便。比如你需要在一個(gè)非 Widget 環(huán)境里做頁面跳轉(zhuǎn)GetX 確實(shí)方便但如果你要配合深度鏈接Deep Link做復(fù)雜路由控制它的處理并不總是靈活。我在一個(gè)大型項(xiàng)目中曾經(jīng)同時(shí)看到過GetX和Provider混用的情況那段時(shí)間真是噩夢。有的頁面用Obx有的頁面用context.watch數(shù)據(jù)流混亂到新人進(jìn)來一臉懵。任何方案最怕的不是它不夠好而是團(tuán)隊(duì)沒有統(tǒng)一標(biāo)準(zhǔn)。4.3 什么樣的人適合選 GetX綜合來看GetX 最適合這幾類場景個(gè)人開發(fā)者、小團(tuán)隊(duì)、原型驗(yàn)證階段、追求快速交付的項(xiàng)目。如果你一個(gè)人又要寫邏輯又要調(diào) UI 又要測后端接口用 GetX 能把狀態(tài)管理、路由、緩存這些事打包解決效率優(yōu)勢非常明顯。但要提醒一句任何項(xiàng)目進(jìn)入長期維護(hù)階段代碼規(guī)范性都會(huì)成為主要矛盾GetX 的“簡便”會(huì)成為一把雙刃劍團(tuán)隊(duì)必須有意識地用紀(jì)律約束開發(fā)節(jié)奏。我自己的經(jīng)驗(yàn)是給團(tuán)隊(duì)定一條規(guī)則GetX 只允許在業(yè)務(wù)模塊內(nèi)部使用禁止跨模塊Get.find亂取數(shù)據(jù)所有跨模塊狀態(tài)必須收斂到統(tǒng)一的倉庫層。5. 硬核對比從架構(gòu)、性能、測試、學(xué)習(xí)成本四個(gè)維度打分5.1 一張表看清三種方案對比維度ProviderBloc / CubitGetX底層原理InheritedWidget ChangeNotifierStream 流式編程改造后的響應(yīng)式編程 依賴注入容器學(xué)習(xí)曲線平緩幾乎無額外概念陡峭強(qiáng)調(diào)單向數(shù)據(jù)流和不可變性極平順一套 API 解決路由和狀態(tài)代碼侵入性低原生 Widget 結(jié)構(gòu)不變中需要引入 BlocBuilder 等組件高路由和狀態(tài)管理深度綁定調(diào)試體驗(yàn)直觀直接用 Flutter Inspector 查樹事件流清晰但鏈路較深Obx 內(nèi)部邏輯較黑盒定位問題需要經(jīng)驗(yàn)單元測試可測但很多邏輯還在 UI 層極優(yōu)純 Dart 邏輯獨(dú)立可測響應(yīng)式便捷但隱式依賴帶來測試難點(diǎn)包體積影響小中較大與 Flutter 核心契合度官方文檔推薦社區(qū)認(rèn)可度高自成一派適合項(xiàng)目規(guī)模中小型項(xiàng)目中大型、多人協(xié)作項(xiàng)目獨(dú)立開發(fā)、需要快速迭代的項(xiàng)目這個(gè)表格是我做技術(shù)選型時(shí)經(jīng)常拿來給團(tuán)隊(duì)講的一張圖。核心結(jié)論很簡單沒有哪一個(gè)方案是絕對最優(yōu)秀的只有和你的團(tuán)隊(duì)、項(xiàng)目、維護(hù)周期匹配的方案。如果你問我個(gè)人偏好我做過從 GetX 遷移到 Bloc 的項(xiàng)目也做過直接用 Provider 的項(xiàng)目不同項(xiàng)目的最優(yōu)解確實(shí)不一樣。5.2 選型判斷的三步走策略我不會(huì)直接告訴你“必須選 X”但我可以分享一套選型判斷模型。第一步評估團(tuán)隊(duì)狀態(tài)管理經(jīng)驗(yàn)。如果團(tuán)隊(duì)成員都是剛轉(zhuǎn) Flutter或者對響應(yīng)式編程、Stream 沒有任何概念直接上 Bloc 的完整版會(huì)讓大家非常痛苦。建議從 Provider 或 GetX 入手等大家理解了數(shù)據(jù)流的基本思想再逐步引入更嚴(yán)格的架構(gòu)。我自己帶新人的時(shí)候一般是讓新人先拿 Provider 練手兩周理解 watch/read 和 ChangeNotifier再去看 Bloc 的事件流思想理解起來就順暢很多。第二步評估項(xiàng)目生命周期和規(guī)模。短期原型、比賽 Demo、一次性上線的工具類 AppGetX 的效率優(yōu)勢非常劃算。要長期維護(hù)的 App、有嚴(yán)格質(zhì)量標(biāo)準(zhǔn)的團(tuán)隊(duì)Bloc 的約束力會(huì)讓后續(xù)迭代更有安全感。而 Provider 則適合那些“已經(jīng)有不少頁面、但狀態(tài)管理還沒形成體系”的項(xiàng)目你可以在不改變整體架構(gòu)的前提下逐步接入。第三步評估業(yè)務(wù)邏輯的復(fù)雜度。一個(gè)只做展示、少量交互的信息流 App用 Provider 就綽綽有余。一個(gè)包含權(quán)限管理、購物車、多步驟表單、實(shí)時(shí)消息推送的復(fù)雜業(yè)務(wù)線你更需要 Bloc 那種顯式事件流否則后期排查數(shù)據(jù)異常會(huì)讓你生不如死。5.3 關(guān)于“混合使用”的一點(diǎn)看法經(jīng)常有人問我能不能在項(xiàng)目里同時(shí)用 Provider 和 GetX我的答案是盡量不要。每種狀態(tài)管理方案都自帶一套完整的數(shù)據(jù)流心智模型混用的結(jié)果就是心智負(fù)擔(dān)翻倍。再遇到一個(gè) bug你得先花時(shí)間搞清楚“這個(gè)值到底是被 Provider 驅(qū)動(dòng)的還是被 GetX 的 Obx 驅(qū)動(dòng)的”。維護(hù)成本遠(yuǎn)遠(yuǎn)大于所謂的收益。但有一種例外場景項(xiàng)目里引入了一個(gè)只用 GetX 寫的第三方插件包或者一個(gè)只依賴 Provider 的庫。這種情況下你無法避免共存此時(shí)我的建議是不要在業(yè)務(wù)代碼里主動(dòng)混用只把第三方庫的實(shí)例封裝成一個(gè)適配層對外統(tǒng)一暴露你自己的狀態(tài)管理接口。這種隔離策略能最大程度減少混亂。6. 實(shí)操分享一次從 GetX 遷移到 Bloc 的真實(shí)經(jīng)歷以前接了一個(gè)團(tuán)隊(duì)項(xiàng)目代碼基礎(chǔ)是 GetX。當(dāng)時(shí)接手時(shí)整個(gè)項(xiàng)目的功能已經(jīng)很豐富但因?yàn)榍捌诘^快狀態(tài)管理這塊已經(jīng)顯露出幾個(gè)嚴(yán)重的問題一個(gè)頁面里散布著大量Obx某個(gè)數(shù)據(jù)的變化被多個(gè)頁面同時(shí)監(jiān)聽定位問題的時(shí)候經(jīng)常順著引用鏈查半天有些 Controller 的生命周期管理比較隨意頁面退出了對象還在內(nèi)存里。團(tuán)隊(duì)的共識是需要更強(qiáng)的結(jié)構(gòu)約束最后我們決定逐步遷移到 Bloc。遷移的過程比預(yù)想的要復(fù)雜但也有一些經(jīng)驗(yàn)可以分享。首先我們沒有做“顛覆式重寫”而是按業(yè)務(wù)模塊逐個(gè)遷移。先挑了一個(gè)邏輯相對獨(dú)立的“個(gè)人中心”模塊做試點(diǎn)把 GetX 的 Controller 邏輯改寫成 CubitUI 層把Obx改成BlocBuilder。效率損失雖然有一些但收益也很明顯模塊的數(shù)據(jù)流向一下子清晰了測試也能直接寫 E2E 級別的邏輯測試了。其次遷移期間我們用了一個(gè)過渡策略在 Bloc 層內(nèi)部兼容舊的 GetX 數(shù)據(jù)源。比如購物車模塊的響應(yīng)式變量在 Bloc 初始化時(shí)先讀一次 GetX 的當(dāng)前值之后 Bloc 自己作為唯一數(shù)據(jù)源把更新后的值同步回舊模塊給其他還沒遷移的頁面兜底。這個(gè)“雙寫”策略雖然不夠優(yōu)雅但保證了大遷移過程中 App 始終可用。還要誠實(shí)地說遷移過程中我們對“性能損耗”是有明顯感知的。Bloc 這種事件驅(qū)動(dòng)模型每個(gè)狀態(tài)轉(zhuǎn)換都要經(jīng)過事件的創(chuàng)建、投遞、響應(yīng)、狀態(tài)比較等環(huán)節(jié)對比 GetX 那種直接改變量、自動(dòng)通知的方式確實(shí)多了一些開銷。但從實(shí)際體感來看在普通交互場景下性能差異并不明顯真正吃性能的還是頁面 build 的頻率優(yōu)化而不是狀態(tài)管理框架本身。最后總結(jié)一下我個(gè)人的體會(huì)狀態(tài)管理的核心目標(biāo)從來不是“選最流行的庫”而是讓團(tuán)隊(duì)用統(tǒng)一的、可以預(yù)測的方式管理數(shù)據(jù)流。我見過用 GetX 做得井井有條的項(xiàng)目也見過用 Bloc 寫得亂七八糟的代碼。框架只是工具決定項(xiàng)目質(zhì)量的是架構(gòu)設(shè)計(jì)和執(zhí)行力。如果你現(xiàn)在正糾結(jié)于選型建議先拿兩個(gè)方案各寫一個(gè)小 Demo跟著官方文檔做一遍然后讓團(tuán)隊(duì)成員投票——選那個(gè)大家都能講清楚原理的方案而不是選那個(gè)名氣最大的。