写这篇文章之前我先说个背景最近团队在做一个新App的预研技术选型会上大家吵得不可开交。有人坚持纯原生iOS有人说RN就能搞定还有人力推Flutter。我坐在那儿听着脑子里想的其实是另一件事无论前端用哪套框架真正决定项目后期是“越写越顺”还是“越改越乱”的往往不是UI组件谁渲染得快而是状态管理怎么设计。这个观察不是什么高深理论而是过去五六年里我在三套技术栈里来回切换、踩坑踩出来的体感。今天就把Flutter、React Native、iOS原生这三条路线上的状态策略完整拆一遍包括各自方案的原理、适用场景、取舍逻辑以及我实际用下来觉得“早知道就好了”的经验。1. 三种技术栈的状态管理本质分别是什么聊取舍之前得先搞清楚这三套东西在状态管理上的起点完全不同。这不是同一个问题有三种解法那么简单而是三套世界观。1.1 Flutter声明式UI与不可变状态的深度绑定Flutter从底层就把状态和UI绑得死死的。它的核心哲学是UI是状态的函数。你给一个widget传入什么数据它就渲染成什么样数据变了widget就重建。这个思路和React那套很像但Flutter做得更彻底。因为Flutter自己实现了渲染引擎整个widget树从创建、比对到重绘都是它自己控制的不需要经过系统原生的UI层。这意味着你可以很频繁地重建widget性能也能扛住——这也是为什么Flutter社区敢大力推行setState和Provider这种数据变了整块重建的方案。但这里有个容易忽视的细节Flutter的重建是分两层的。上层是widget对象的创建和销毁这一层很廉价下层是Element和RenderObject的复用与更新这一层才是真正绘制相关的逻辑。所以做状态管理时你要关心的是数据变化后哪些Element和RenderObject需要更新而不是哪些widget被重新new出来了。一个常见误区是用Provider或Bloc把整个页面包在一个大Builder里任何局部状态一变整个页面build方法全跑一遍。虽然widget对象的创建开销不大但如果你的build方法里有重度计算、有不需要变化的子树没有做const优化帧率照样会被拖垮。很多团队说Flutter性能不行十有八九是状态粒度没控好而不是Flutter本身的问题。1.2 React NativeJavaScript生态的灵活与混乱并存RN则完全是另一套逻辑。它跑在JavaScript引擎上状态管理方案直接继承了Web生态那一大堆库Redux、MobX、Zustand、Jotai、Recoil还有React自带的useState、useReducer、Context。这种多样性的好处是选择多坏处也是选择多。团队里但凡缺一个有全局视野的技术负责人很容易出现一个小功能引三个状态库的奇观。我见过一个项目Redux、MobX、Zustand三个库共存问起来就是这个新来的同事用着顺手就加进来了。相比之下Flutter虽然也有Provider和Bloc之争但至少社区基调相对统一新人在状态管理上的试错成本没RN那么高。不过RN有一个Flutter比不了的优势它和Web生态是打通的。如果你的团队本身有React开发经验那RN的学习曲线几乎等于零状态管理方案也直接复用不需要重新学一套模式。这个团队已有能力的价值在项目排期紧的时候会被无限放大。1.3 iOS原生从MVC到MVVM再到SwiftUI的演进iOS原生这边情况又不同。UIKit时代大家惯性用的是MVC——ViewController既管视图又管状态又管网络Controller臃肿到几万行的项目比比皆是。后来MVVM开始流行配合ReactiveCocoa或RxSwift把状态从ViewController里剥离出来放到ViewModel里再通过数据绑定驱动UI。但iOS真正的转折点是Combine和SwiftUI的引入。SwiftUI的整个开发方式几乎就是照着Flutter/React那套声明式思路来的视图是状态的函数状态变化触发视图自动更新。配合State、ObservedObject、EnvironmentObject这些属性包装器状态管理变得非常直接。这里就出现了一个有意思的交叉Flutter和SwiftUI在状态管理哲学上高度相似都是单向数据流声明式UI而RN反而因为JS生态的灵活性容易写出状态满天飞的代码。2. 各技术栈主流状态方案的真实体验方案选型这种事不能只看官方文档吹得多好得放在真实场景里验证。我把三套技术栈里我实际用过、并且有足够样本量的方案逐个过一遍。2.1 Flutter阵营setState、Provider、Riverpod、Bloc的适用边界setState。最简单也最容易理解。一个StatefulWidget内部的数据变化用它就够了。我的经验是凡是只在单个widget内部生效、不跨组件共享的状态无脑用setState就对了。比如一个可展开卡片、一个搜索框的输入内容、一个Tab内部的加载中标志。非要把这些塞进全局状态管理里属于给自己找麻烦。Provider。这是Flutter官方文档早期推荐的方案核心是InheritedWidget的封装。它解决了跨组件依赖的问题你可以在组件树上层放一个ChangeNotifier下层任意widget通过context.watchT()取到数据并自动刷新。Provider的优点是入门门槛低没有概念负担。但它有几个问题一是模式松散ChangeNotifier里的状态是可以随意改的项目大了以后很容易改出不可预测的依赖关系二是依赖BuildContext有些场景下比如异步回调里用起来很别扭。我在小项目里用Provider很顺手但团队项目规模上来以后就开始力不从心了。Riverpod。这是同一个作者后来推出的重写方案算是Provider的增强版。它解决了Provider的很多硬伤不依赖BuildContext、编译期安全、支持自动取消、测试友好。Riverpod的几个概念——Provider、StateProvider、StateNotifierProvider、FutureProvider、StreamProvider——初看有点多但用顺了以后会觉得每一条都有明确用途。我自己现在做新项目Flutter这边默认就是Riverpod。它最打动我的一点是所有依赖在编译期就确定了不会出现在运行时才报ProviderNotFound这种低级错误。Bloc。这是dart团队出的官方推荐方案之一现在不止一个还有flutter_riverpod也是官方推荐的核心思想是事件驱动UI发事件Bloc接收事件经过业务逻辑处理后输出新状态UI订阅状态并重新渲染。Bloc的优点非常明显单向数据流极其清晰业务逻辑完全独立于UI测试时可以单独测Bloc不用渲染任何widget。这对于中大型团队、有明确分层要求的项目来说是最稳的架构。但Bloc的缺点也很突出样板代码太多了。一个简单的计数器用setState只需要几行用Bloc得建三个文件Event类、State类、Bloc类每个还可能要写不少重复代码。团队如果规模小、迭代快Bloc很容易被嫌弃效率低。2.2 RN阵营Redux、Zustand、MobX之间怎么选RN这边选择更多反而更考验判断力。Redux配合Redux Toolkit。这是最传统的方案全局store action reducer单向数据流逻辑清晰配合devtools可以时空旅行调试。在大型复杂应用里Redux的约束力能让状态变化变得可预测。但原生Redux的样板代码问题比Bloc还严重所以后来出现了Redux Toolkit来简化这些样板。我个人的建议是如果要用Redux必须用RTK别再用手写actionCreator和reducer的老方式了。Redux适合的场景是全局状态多、跨页面共享频繁、需要对状态变化做严格追溯的项目。Zustand。这是近几年风头很盛的一个方案以少样板、使用简单著称。它的核心思路是一个hook就是一个store整个store还是一个全局对象但通过选择器可以精准订阅局部状态避免不必要的重渲染。我用Zustand的感受是真香。写起来几乎没负担状态定义、更新、订阅全部在一个文件里搞定学习成本比Redux低一个数量级。而且它的性能很好因为可以实现状态没变就不触发组件更新。Zustand适合的场景中小型项目、状态数量适中、团队希望减少概念开销。MobX。响应式编程思路状态是可变对象任何属性被修改时依赖它的组件自动更新。写起来代码量很少开发效率高。但MobX有个老问题响应式链路是隐式的状态变化太聪明了反而容易让人失去对数据流的控制感。项目一复杂你很难判断某个状态为什么变了排查起来靠猜。小项目用它很爽大项目要有很强的纪律才能用好。我的建议是RN项目如果团队小、状态简单Zustand就够了如果团队大、历史包袱重、严格的数据流管控优先选ReduxRTKMobX除非团队里有对它非常熟悉的人否则不建议新项目引入。2.3 iOS阵营UIKitMVVM、Combine、SwiftUI的状态链路iOS原生的状态管理在SwiftUI出现之前其实没有一个被广泛认可的统一方案。部分原因是UIKit时代UI和状态天然分离IBOutlet连控件代码更新UI的显示。这给了开发者很大的自由度也让状态管理变得没有标准答案。UIKit MVVM Combine。这是iOS原生目前比较成熟的模式ViewModel持有状态通常用Published包装ViewViewController订阅状态的变化来更新UI。配合Combine的Published和ObservableObject可以做出类似Flutter/Riverpod的效果数据流清晰UI自动更新。但Combine有个门槛它只支持iOS 13。虽然现在基本不需要考虑更老的系统了但如果你要兼容旧iOS版本还得继续用RxSwift或者手动绑定。SwiftUI。SwiftUI的状态管理和Flutter高度雷同State是widget局部状态ObservedObject和EnvironmentObject是跨组件共享状态AppStorage是轻量级持久化。用起来和Flutter的setState/Provider体验非常接近。不过SwiftUI有一个现实问题它不支持低于iOS 13的系统实际上很多高级特性要求iOS 15甚至17而且目前仍有部分复杂UI场景需要回落到UIKit。所以纯SwiftUI实现大型应用在现阶段还是有风险的选择——我建议胆大的可以选SwiftUI但必须做好极少数页面用UIKit兜底的预案。2.4 一个跨端场景的接口对比为了更直观地感受差异我把三套技术栈在同一个需求下的状态管理实现方式列出来对比。假设需求是从服务端加载用户列表支持下拉刷新展示加载中/成功/失败三种状态。技术栈状态建模方式异步处理UI更新方式Flutter RiverpodAsyncValueAsyncNotifierref.watch监听自动重建Flutter Bloc枚举状态数据对象Bloc内异步逻辑BlocBuilder按状态分支渲染RN Redux Toolkitslice状态reducerscreateAsyncThunkuseSelector订阅切片数据RN Zustandstore中的状态actionsasync方法直接改状态useStore订阅局部状态iOS SwiftUIState/ObservedObject.task修饰符或async方法状态模型变化自动触发body更新iOS UIKit CombinePublished属性Future/async sink订阅Published变化更新UI看完这张表你会发现一个规律状态管理方案的复杂度取决于你对数据发生变化的路径的管控力度。Riverpod、Bloc、Redux都属于强管控Zustand中等setState和State是弱管控。强管控的代价是样板代码多收益是状态可追踪、可测试弱管控代价是调试靠猜收益是起步快。3. 场景化取舍到底什么时候该选哪个理论讲再多不如回答一个现实问题我现在这个项目到底该用什么这个问题没有统一答案但我可以根据项目特征给出几个判断维度。3.1 按项目规模与团队判断个人项目或原型验证不需要纠结Flutter就用setState局部状态必要时加个ProviderRN就用useStateuseReduceriOS就用State。先让功能跑起来比什么都重要。等到原型转正、需求开始堆积时再看哪个状态被频繁跨组件共享把那一块抽成正式的状态管理层就行。中小型商业项目10人以下团队半年内上线Flutter优先推荐RiverpodRN优先推荐ZustandiOS优先推荐SwiftUIMVVM。这三个方案的学习成本低、开发效率高、逻辑不容易散架。它们对团队纪律的要求没那么高就算团队成员水平参差也不至于把项目写成一坨。中大型项目30人以上团队多业务线并行Flutter上Bloc基本是首选因为它强制的分层能约束团队各做各的RN上ReduxRTK仍然是更稳妥的选择Zustand那种灵活风格在人多以后容易失控iOS则要看你是UI层用同一个团队还是分两个团队如果分团队SwiftUI的声明式风格和UIKit的Controller风格差异会很大最好统一。3.2 按状态类型判断状态管理方案不该一刀切应该按状态类型分而治之。我把移动端的状态粗略分成四类UI临时状态弹窗是否可见、Tab当前选中项、下拉刷新是否加载中。这类状态生命周期极短只在单个页面内流动用最轻的方案就行——setState、useState、State。跨页面共享状态用户登录信息、应用配置、购物车数据。这类状态需要全局共享且多个页面都会读取和修改要放在全局状态管理里——Riverpod的StateProvider、Zustand的store、SwiftUI的EnvironmentObject。服务端状态从接口拉取的业务数据需要处理加载中/成功/失败/刷新/缓存这些状态。很多团队把服务端状态当成普通全局状态来管Redux里存一大堆loading标志这是坏味道。这类状态更适合用专门的方案比如Flutter的FutureProvider、RN的React Query尽管它主要面向Web但在RN里同样可用、iOS原生可以自己封装一个异步加载容器或者用Swift的async/await直接把状态模型写在View里。路由/导航状态当前是在哪个页面、要回退到哪里。这部分通常不需要手工管理框架已经帮你做了。除非你要实现复杂的导航拦截逻辑比如登录后才能访问某些页面否则不建议把这部分状态放进全局store——我见过有人把navigation的状态硬塞进Redux结果导致路由跳转的时序问题排查了很久。3.3 按团队技能矩阵判断这一点很容易被忽视但非常重要。状态管理方案好不好用不是看方案本身多优秀而是看团队能不能持续正确地使用它。一个纯UIKit背景的iOS团队你突然要求他们转FlutterBloc那条学习曲线是很陡的得先理解widget树和Element树的关系又得理解事件驱动的状态流转还得适应dart的语言风格。这种情况下与其强推Bloc不如先用Provider让他们把业务跑起来等团队对Flutter有感觉了再逐渐引入Riverpod或Bloc。反过来一个React出身的团队转RN状态管理几乎没有学习成本直接上Redux或Zustand就行这时候纠结的反而只剩用哪个库而不是怎么学。团队因素往往比技术因素更容易决定方案成败。我见过太多别人推荐什么我上什么的项目最后因为团队消化不了落得个技术栈七零八落的下场。3.4 按性能敏感度判断如果你做的App对性能敏感——比如高帧率动画、实时视频处理、大量图表绘制——那么状态管理方案的粒度很重要。Flutter这边Bloc和Riverpod都支持细粒度的监听。但重点在于你有没有做好widget的const优化和RepaintBoundary隔离。我见过一个项目用Bloc但因为一个状态对象里塞了整个页面的数据导致任何子状态变化都会触发整页重建性能直接崩掉。这不怪Bloc怪状态建模没做好。RN这边Zustand因为支持selector能很好地做到哪个组件用哪个状态就只在那个状态变化时重渲染。而Redux如果不配合useSelector的浅比较或者reselect做记忆化很容易出现大范围重渲染。iOS的SwiftUI性能问题主要集中在body被无效触发。用ObservedObject时如果ViewModel里的任何Published变化所有依赖这个ViewModel的视图都会重新求值body。优化策略是把大ViewModel拆成多个小ViewModel或者把Published的粒度做细。4. 工程实战中的状态设计经验与避坑指南方案选好了工程实践里还有一堆细碎的坑在等着。这些经验不是文档里能看到的都是项目线上踩出来的。4.1 跨页面状态同步的单一真相源跨页面状态同步是状态管理里最容易出问题的地方。根本原因在于一个状态被存在了多个地方改了这个忘了那个。我举一个我们在RN项目里遇到过的问题两个Tab页都要显示我的收藏数收藏按钮在详情页。收藏数在store里存了一份详情页页面里又本地存了一份。用户收藏后store里的数字更新了但详情页的本地副本没同步切回来一看还是旧数字。解决办法就是确立单一真相源原则一个状态只存在一个地方。详情页需要的收藏数必须从store里读不能再local一份。Flutter里是一个Provider只负责一块状态iOS里是一个ViewModel只归一个页面所有RN里是一个state只属于一个store或一个hook。听起来很简单但团队越大越容易有人贪图方便图省事在局部又存了一份。我现在的做法是code review时明令禁止重复存储同一业务数据一旦发现必须当场改掉。4.2 状态持久化与冷启动恢复很多状态只有在App运行期间有效但有一部分状态需要跨启动保存比如用户登录态、上次访问的页面、草稿内容。Flutter这边常用shared_preferences或者氢文档里的flutter_secure_storage来持久化。Riverpod里可以写一个Provider来管理初始化时从本地读取运行时写入的逻辑。RN这边redux-persist可以自动把store里的部分状态同步到AsyncStorageZustand有官方的persist中间件。用起来很方便但要注意不要把所有store都自动持久化。有些临时状态比如弹窗状态、表单输入暂存被持久化后会造成意想不到的行为——比如用户切到后台又回来发现上次输入一半的内容还在但这可能和真实业务不符。iOS这边UserDefaults适合存轻量数据CoreData或者SwiftData适合存大块结构化数据。AppStorage可以轻松把一个State绑定到UserDefaults适合存用户偏好。这里有个容易踩的坑持久化的数据结构一旦上线后续改字段就必须考虑迁移。尤其是iOS和RN都遇到过老用户本地缓存结构和新代码不匹配导致崩溃的情况。建议所有持久化状态都带上版本号字段做读取时检查和迁移。4.3 团队协作中的状态规范状态管理方案再统一如果团队没有使用规范最后还是会被写成人人大不相同。我开始带团队后强制推行了几条状态管理规范三条核心第一明确数据流方向。Flutter和Redux、Bloc这类单向数据流框架做到这点比较容易但RN的Zustand和setState混用时容易弯掉。我规定UI事件必须通过明确的方法来更新状态禁止在组件里直接改store里的对象。第二状态命名要语义化。不要起isLoading这种极度模糊的名字至少得是isUserListLoading。多几个字不费事但排查问题时会省很多时间。第三禁止在build/render方法里做状态计算。Flutter里build方法可能被触发得非常频繁如果里面包含昂贵的计算性能直接塌方。正确做法是计算放到状态初始化或者bloc里build方法只做纯展示。另外还有一条经验状态管理库的版本升级要慎重。Flutter的Riverpod从1.x升到2.xAPI变动很大RN的Redux Toolkit、MobX每次大版本都可能引入破坏性变化。升级前必须看变更日志并且要有一个最低限度的状态回归用例集——不用覆盖所有业务但核心状态流转必须有测试兜底。4.4 测试视角下的状态管理状态管理做得好不好一个重要的检验标准是好不好测。Bloc在这点上做得很好因为逻辑和UI完全分离你可以直接实例化Bloc发事件断言输出状态完全不依赖widget测试。Riverpod的Provider化设计也让状态测试变得很容易可以覆盖失败重试加载中不重复发起请求这类逻辑。RN这边Redux的纯reducer天然可测Zustand的store也可以直接import进来调用。真正难测的是MobX的响应式链路——因为状态变化是自动发生的你不好控制哪一刻触发哪个依赖更新写测试时常常要配合autorun来手动断言。iOS里SwiftUI的状态管理可以用ViewInspector之类的库来做UI层测试但更推荐把核心业务逻辑下沉到ViewModel里单独测。封装好依赖注入后你甚至可以在测试里用假数据注入ViewModel模拟成功/失败路径断言状态是否正确变化。4.5 热词相关的几个实战场景补遗写到这里顺带把项目标题相关的几个热搜词背后的实际场景也补充几句。flutter bloc教程——Bloc确实值得花时间学但我建议先掌握Riverpod再学Bloc。因为Riverpod的概念更贴近响应状态变化的直觉而Bloc的事件驱动模式需要一点适应时间。学Bloc时不要一开始就硬套分层架构那套先把三件套Event、State、Bloc跑通再逐步引入Repository层。rn调用电话功能、图片裁剪rn库——RN生态里有很多这种细碎功能库引入前一定先确认它是否持续维护。RN的第三方库是重灾区很多库作者坚持维护两年就放弃了最后项目里留一堆没人修的坑。我的习惯是看GitHub stars数和最近的commit时间低于一年没更新的直接找替代品。ios自动化——状态管理里也和自动化相关比如用XCUITest做UI自动化测试时状态的可预测性直接决定测试稳定性。如果你的App状态管理很乱UI自动化测试大概率也是三天两头挂。反过来一个状态管理清晰、数据流可控的AppUI自动化测试几乎不用额外做太多处理就能跑得稳。impeller——如果说状态管理是Flutter应用的骨架那Impeller就是血肉。Impeller是Flutter的新渲染引擎解决了Skia在iOS上的长期性能抖动问题。它对状态管理本身没有直接影响但它带来的渲染性能提升意味着你可以更放心地采用整体重建式的状态管理方案而不用担心动画卡顿。5. 写在最后状态管理是长期主义的选择说了这么多回到那场技术选型讨论会。我当时没有争论哪个框架好而是问了一个问题咱们这个项目后续是一个月改一轮需求还是半年后才上线答案不同状态方案的取舍完全可以反过来。状态管理这件事本质上是在短期效率和长期可维护性之间做权衡。你用setState、State、useState起步前期写得飞快但项目复杂度上来了重构成本会翻倍你一开始用Bloc、Redux前期多点成本但进入维护期后改业务就像搭积木一样清晰。我个人这些年形成的习惯是三个原则供你参考第一状态模型跟着业务走不跟框架走。先把业务实体的关系捋清楚再想用什么技术方案承载它。业务建模没做好用再高级的状态管理库都是白搭。第二用最简方案解决现状但保留升级路径。哪怕一个小功能也要知道如果它哪天变复杂了应该往哪个方向重构。管理状态和装修一样能一步到位的地方别省不能一步到位的地方留好接口。第三共识比技术优先级高。不管选哪套方案团队里所有人都得按同一套规范来写。状态管理不是某个人写得爽就行而是所有人都能读得懂、改得动。移动端的状态管理也许没有一个永远正确的答案但一定有一个当前阶段最不坏的选择。希望这篇文章能帮你找到它。