企业官网建设流程全解析

入行这些年，我聊过不下十次“Flutter / RN / iOS 状态策略怎么选”这类话题。每次聊到后半段，都会从技术分析滑向框架信仰之争：有人说 Bloc 才是 Flutter 的正统，有人说 Redux 的样板代码是灾难，还有原生党直接抛出一句“你们跨端方案的状态管理，最后不都得绕回我们 iOS 那套 MVC 逻辑吗”。吵到最后，问题往往不是技术不行，而是大家把“状态策略”当成了技术选型，却忘了它本质上是个工程管理问题。

这篇文章我想换个角度聊——不站队，不吹某个框架，而是把 Flutter、React Native、原生 iOS 三条路线的状态管理方案放在一起拆开看。我会从状态本身的类型出发，盘点三个生态各自的主流方案，再聊几个真正影响取舍的隐性成本，最后给出一些我自己在不同项目里验证过的组合套路。不管你是独立开发者、小团队的技术负责人，还是正在从原生转跨端的同学，这篇文章应该都能给你一些可落地的参考。

1. 先搞清楚你在管理什么状态：三分法比框架之争更重要

很多人一上来就问“Flutter 用 Bloc 还是 Riverpod”“RN 用 Redux 还是 Zustand”，但我觉得这个问题问早了。状态管理方案是工具，你得先弄清楚自己到底要管理什么状态，工具才有讨论的意义。

我自己的习惯是把业务里的状态粗暴地分成三类。第一类是服务端状态，也就是需要和接口打交道的数据——用户信息、订单列表、消息未读数。这类状态的核心特征是它有唯一事实来源，服务器说了算，客户端只是缓存，需要考虑的是拉取时机、缓存失效、失败重试，而不是什么优雅的不可变更新。第二类是客户端本地状态，比如表单的输入内容、弹窗的开关、Tab 的选中项。它的特点是生命周期短、作用域窄，大部分时候根本不需要全局状态管理工具，一个局部变量就够了。第三类是共享协作状态，比如登录态、购物车、主题配置，这类状态要被很多页面读取、被很多模块修改，而且修改后要通知所有依赖方刷新——这才是状态管理框架真正要解决的硬骨头。

你把这个分类先立起来，再去看各个技术栈的方案，思路会清晰很多。比如 Flutter 里有人抱怨 setState 太原始，但大多数表单页面、折叠面板，用 setState 反而是最直接、最好调试的，硬上 Bloc 只会让简单的事情变复杂。RN 那边有人骂 Redux 过重，但如果你的购物车、用户偏好要被几十个组件共享，Redux 的单一数据源和严格的数据流恰恰是降低心智负担的。iOS 原生也一样，很多小型页面用 delegate 回调完全够用，没必要一上来就摆出 TCA 的全套架构，等到页面间的状态纠缠到你改一个开关要联动三个控制器时，再上架构不迟。

还有个容易被忽略的点：这三类状态的边界不是固定的，它会随着业务演进跨类。我今天写了个登录表单，用的是纯本地状态，明天产品说要让用户在填完邮箱后立刻看到会员身份的预展示，这个表单就直接变成了需要服务端校验的协作状态。这也是为什么我建议团队在每个页面开发前，先花十分钟把页面涉及的状态按这个三分法写出来。不是为了写文档，而是为了逼自己确认状态的生命周期和共享范围，这一步做完，“要不要引入全局状态库”的答案往往就自己浮出来了。

2. 三个阵营的现状盘点：Flutter、RN、原生 iOS 谁更省心

分类看完，我们落到具体工具。这部分逐个生态过一遍，我会少讲概念，多讲真实工程里的感受。

2.1 Flutter：从 setState 到 Riverpod，有清晰的成长路径

Flutter 的状态管理生态有一个很有意思的特点：它有一套内置的、从简单到复杂的成长路径，而且官方并没有强制你必须用哪个。最底层的是 StatefulWidget 自带的 setState，适合管理真正局部的 UI 状态；往上一点是 InheritedWidget，Flutter 框架内部大量使用它来做主题、本地化的透传，但它自己用起来有点啰嗦；Provider 把 InheritedWidget 封装成了好用的依赖注入 + 通知机制，一度是官方推荐的首选；再往上是 Riverpod 和 Bloc，两者代表了两种不同的设计哲学。

Riverpod 是 Provider 作者 Remi Rousselet 推出的重构版，最大的改进是摆脱了对 BuildContext 的依赖，组件可以在没有 Widget 树上下文的地方被读取，这让测试和复用变得舒服很多。它的编译期安全性也做得很好，很多错误在 IDE 里就能指出来，而不是跑到运行时才炸。Riverpod 还支持按依赖粒度刷新，你可以让组件只监听 store 里的某一个字段，避免整个页面因为一个无关状态的变化而重建。这一点在列表页尤其重要——你可能只是想更新某一条数据的点赞数，但一个粗暴的全局状态监听可能会让整个 ListView 全部 rebuild，这在滑动场景下是会掉帧的。

Bloc 则是另一个极端，它把状态管理硬性拆成 Event（事件）和 State（状态），所有变化必须通过事件的派发来驱动。它的好处是逻辑的流转路径非常清晰，团队成员看着代码就能复现完整的业务链路，适合中大型团队做规范约束；代价是样板代码量大，一个简单的计数器也要写好几个类。我自己见过不少团队上了 Bloc 之后，光维护 event/state 文件就占用了大量开发时间，反而拖慢了迭代速度。如果你是非要用 Bloc 的情况，优先配上官方的 code generation 或者 bloc 扩展插件去自动生成模板，不然纯手写会写到怀疑人生。

这里多说一句，Flutter 社区里还有一个叫 GetX 的全家桶方案，很多人因为它的便捷性和高性能入坑，但它把路由、依赖注入、状态管理、国际化全部捆在一起，而且大量使用全局单例，在大型项目里容易让状态出处变得混乱，出现“每个人写的 GetX 代码风格都不一样”的情况。我的建议是，早期原型或者工具型 App 用它没问题，但如果是准备长期迭代的商业项目，最好在 Riverpod 和 Bloc 里选一个，至少它们的边界清晰，团队流动时的交接成本低。

2.2 RN：Redux 老而弥坚，但 Zustand 这类轻量方案正在上位

RN 的状态管理生态是 JavaScript 社区的直接映射，表达能力很强，可选余地很大，但选择困难症在这里也会比较严重。老牌代表 Redux 经历了完整的生命周期，它强调单向数据流、单一 Store、纯函数 Reducer，配合 Redux DevTools 可以查看完整的状态变更日志，甚至时间旅行调试。这些特性在 Web 时代帮助无数团队建立了“状态变更要有迹可循”的工程纪律，在 RN 里也依然成立。但 Redux 的原生写法样板代码确实多：定义 action 类型、创建 action 创建函数、写 reducer、再配 combineReducers……一套下来，加了网络请求和中间件之后，新人光理解 data flow 就要花不少时间。

好在现在很少有人再用裸 Redux 了，官方主推的 Redux Toolkit（RTK）已经把大量模板收敛掉了。RTK 里我把状态切片写成 createSlice，reducer 和 action 会一次性生成，配合 createAsyncThunk 处理异步请求也很顺手。如果你看到很多新项目同时选了 redux 全家桶，大概率用的是 RTK 这一套改良后的方案，而不是当年的经典三件套。

而在轻量这一侧，Zustand 和 Jotai 是这两年我最常被人问到的。Zustand 的核心思路很直接——一个可外部访问的 store，不需要 Provider 包裹，组件里直接用 hook 读取状态，按 selector 做精准订阅，性能好，心智负担低。Jotai 则更进一步，把状态拆成原子级的最小单元，然后通过原子的组合来派生出新状态，适合状态交互关系复杂的场景。相比 Redux，这两个方案几乎没有学习曲线，写了 Hook 的人半小时就能上手。但我得泼一点冷水：正因为上手太容易，很多团队会忽略对状态文件夹做结构规划，写几天之后 store 文件里全是一大堆随手创建的状态碎片，到了后期想梳理依赖关系反而比 Redux 的强约束更麻烦。轻量化不等于是免维护，这一点我后面还会展开。

RN 生态里还有 MobX，它走的是响应式可变状态路线，写起来很有“魔法感”，@observable 和 @computed 配合起来代码量特别少。我以前一个项目用 MobX 写过库存联动逻辑，体验非常爽，但团队的成员若是习惯了 React 的不可变哲学，会对 MobX 的追踪机制有很强的违和感，排查 bug 时也常常要找“这个 observable 是被谁改的”。MobX 不是不好，而是它的心智模型和 React/RN 主流范式有分歧，引入前要有全队达成共识的觉悟。

这里提一下紧跟进程的动态，RN 新老架构对比是目前社区里的热门话题。新架构里 Fabric 渲染器和 TurboModule 改变了频繁跨桥通信的性能瓶颈，对状态管理的影响也在慢慢显现：以前我们为了减少跨 bridge 传递状态而做的很多性能 hack，在新架构里会变得不那么必要；但新架构也还没有完全消除 JS 和原生之间的序列化成本，该避免的高频整树刷新还是得避免。如果你要让团队直接上一个还在演进中的新架构项目，建议状态方案先选自己最熟的那一套，别在“新技术 + 新架构 + 新状态库”的三重叠加里做第一个吃螃蟹的人。

2.3 原生 iOS：从 MVC 到 SwiftUI，状态管理的重心在变

原生 iOS 的状态管理话题，过去十年基本是被 MVC、MVVM 和 ReactiveCocoa/Combine 这几个词统治的。传统 UIKit 时代，Controller 里塞满数据和事件回调是常态，状态泄露、ViewController 膨胀几乎是每个 iOS 老兵的伤疤。MVVM 的出现把业务逻辑搬到了 ViewModel，配合 ReactiveCocoa 的 RACSignal 或者现在苹果官方的 Combine，算是给控制器减了负。但 MVVM 的绑定层同样容易失控——一个 ViewModel 里的发布者可以串出一张看不见的依赖网，视图对值的订阅究竟被谁触发过，调试起来并不轻松。

SwiftUI 发布之后，原生 iOS 的状态管理从一个回调思维转入了声明式思维，这个转变比多数人想象的要大。过去我是“先有数据，然后主动去赋值给 Label 的 text”，现在我是“把 @State 当作视图的属性，数据一变化，视图自己重算”。这套心智和 Flutter 的“Widget 是状态的函数”其实是同构的，所以如果你在 Flutter 里用过 setState、InheritedWidget，再去看 SwiftUI 的 @State、@Binding、@EnvironmentObject，会发现非常亲切。

今年苹果把 Observation 框架和 @Observable 宏进一步提升到了更核心的位置，用来取代之前的 ObservableObject + @Published 组合。这个变化对老项目而言是一次不小的迁移成本，但对新项目来说是好消息：@Observable 宏用起来更像普通属性，视图对状态的订阅也更精细，不再动不动整个 body 刷新。再加上 @State、@Binding、@Environment、@EnvironmentObject 这一整套作用域体系，SwiftUI 已经能覆盖从组件级局部状态到 App 级全局环境的所有粒度。只是要注意，SwiftUI 这套体系强依赖 OS 版本，如果你的业务还需要大量兼容旧版本，那 Combine + UIKit 的过渡方案依然是绕不开的现实选择。

至于 TCA（The Composable Architecture），它是 Point-Free 在 Swift 函数式编程框架下做的一套类 Redux 架构，社区热度和争议都很大。它强调一切都是 reducer + action + state 的三角流转，配合副作用管理，能构建出测试性极强的业务核心。我在一个投资类 App 里见过 TCA 的实践，对金额计算、多步表单这类复杂链路确实友好，但团队必须对“每个 action 要显式处理所有 state 变化”这种高纪律性写法有充分准备，否则会是交付效率的黑洞。

2.4 三个生态的关键差异对照

用表格把三者的主流方案做个横向对照，方便你快速找定位：

说实话，这三条路线没有哪个在“省心”上能一锤定音。Flutter 的集成度高，但生态里方案太多也容易内耗；RN 的生态活力最强，但过度繁荣同样带来选择成本；原生 iOS 的稳定性和系统融合度没得说，可要在跨平台上就直接出局了。关键还是回到你的项目和团队现状。

3. 影响取舍的三个隐性成本：团队画像、渲染机制与热更新

前面聊的都是状态管理的“内功”，接下来聊三个藏在水面下的因素。这三个因素平时很少出现在框架评测文章里，但我在真实项目里发现，它们往往才是决定状态策略能否长期跑下去的胜负手。

3.1 团队画像：状态库的“约束度”要和团队自律度匹配

我见过一个极端的反例：某团队用 Flutter 做中后台 App，状态管理选了 GetX，理由是开发快、代码少。结果项目跑了一年，几十个页面各自 getx 单例随手新建，数据流变成了“谁想起来谁写一笔”，每次版本迭代光是排查共享状态从哪被弄脏就要耗掉两三天。团队内部还发生过“到底该不该再建一个新的 Controller”的争议——因为没有明确的规则，谁都不认为自己有错。

这个案例让我想明白一件事：状态管理工具本质上是一种团队协作契约。它的约束力越强，对团队纪律的要求反而越低；约束力越弱，团队就越需要一个技术核心来制定并执行规则。所以选型前先看看自己团队：是全员自驱、代码评审严格，还是需求多、节奏快、成员水平参差？如果是前者，Zustand、Riverpod 这类轻快方案完全没问题；如果是后者，你可能更需要 Bloc、Redux Toolkit、TCA 这种“规范替你说话”的方案。团队画像这关过不去，再优秀的框架也救不了项目的状态混乱。

3.2 渲染机制：状态刷新频率和重建粒度的关系

第二个隐性成本来自渲染引擎本身。Flutter 的 Widget 不可变 + 重建机制让“精准重建”显得特别重要，我在 Flutter 项目里最常见的性能问题，不是算法多复杂，而是某次 setState 或 Provider 的值变化触发了整棵子树重建。社区里聊得多的 Impeller 引擎，主要优化的是渲染管线的光栅化性能，但如果你在状态管理这一层就时不时把整个列表页重画，再快的渲染引擎也救不了滑动流畅度。所以 Flutter 里做状态管理，务必关心监听粒度：Riverpod 的 Selector、Provider 的 Selector、BlocBuilder 的 buildWhen，这些机制不是可有可无的语法糖，而是性能安全网。

RN 这边要提防的是“跨桥高频更新”的坑。老架构里 JS 层状态一变，要通过 bridge 通知原生视图更新，高频状态下（比如连点、拖拽进度条实时更新）很容易出现卡顿；新架构的 Fabric 虽然改进了交互手势和渲染的响应路径，但高频更新成本依然不是零。我的经验是，RN 里凡是需要高频更新的状态，尽量通过 reanimated 这类直接驱动 UI 的库去处理，别让 React 层的 setState 和 re-render 成为瓶颈。这也是为什么我前面强调 Zustand 的精准订阅——它在这些场景下的价值是实打实的。

iOS 原生相对好一些，因为 SwiftUI 的依赖跟踪精度很高，UIView 层级也是直接操作，没有中间的跨技术栈损耗。但 SwiftUI 里过度使用 @EnvironmentObject 会在大型 App 里造成必现的整树刷新问题——一个全局环境对象的值变了，所有依赖它的视图都会重新评估 body。这时候你需要考虑把 @EnvironmentObject 拆细、把依赖粒度收紧，而不是把所有东西一股脑塞进全局环境。

3.3 热更新与版本策略：状态管理方案能不能跟系统一起升级

第三个隐性成本是热更新与系统版本。iOS 原生基本没有 JavaScript 层面的热更新空间，你的状态管理方案一旦和系统 API 绑定太深（比如依赖新的 Observation 框架），就得为系统版本覆盖率买单。很多团队现在还心存侥幸不愿意升级 iOS 基线版本，导致新方案只能写在 Demo 里，没法真上生产。RN 这边理论上可以走 CodePush 这类热更新，但前几年各大市场对于热更新的合规态度一直在变，不少团队实际上已经减慢了 RN 代码直接推送的节奏。Flutter 一直不支持官方热更新，这也是现实，所以状态管理方案里涉及的核心逻辑，你必须在打版本前就测透。

我提这些不是说哪个方案因此不能选，而是提醒你把状态管理方案放在“系统的长期版本策略”里去评估。不要只看今天能不能跑通，要看它能不能在你未来一年的系统升级节奏里保持稳定。比如你已经决定 App 最低支持版本可以提到 iOS 17，那 @Observable 就会比兼顾旧版本的 ObservableObject 方案更值得优先考虑；如果你还要支持 iOS 15 用户，那就别在核心路径上冒迁移风险。

4. 落到具体场景：我推荐的组合套路与踩坑经验

有了前面的分析，最后给几个我验证过的组合建议。这里的“组合”不单指某个状态库，而是“状态策略 + 组织策略 + 工程实践”的整体套路，照着参考比单纯抄库更实用。

4.1 独立开发者和早期产品：选“能撑半年”的方案就够

如果你是一个人开发，或者产品还在验证期，我的建议是别选太重、纪律要求太高的状态方案。Flutter 侧用 Riverpod，理由是它灵活、测试方便、不用挂 Provider 树，写起来像写普通代码；RN 侧用 Zustand，理由同样简单直接；如果你想在 SwiftUI 里做原生小项目，直接用 @State + @Observable + 少量 @Environment 就好。

这套组合的核心逻辑是：快速交付优先。早期产品的状态复杂度通常不会爆炸，轻量方案足够覆盖；万一后续真复杂起来了，Riverpod 和 Zustand 都具备“渐进式重构”的空间，不至于推到重来，硬上 Bloc 或 Redux 反而让原型期拖慢你的验证速度。

4.2 小到中型团队：用“分层纪律”弥补轻量方案的自由度

到了两三个到十几个人的团队阶段，问题就不是“选什么库”了，而是“用了这个库之后怎么约束大家”。我的做法是用分层纪律去补约束：不管在 Flutter 还是 RN 里，都明确分成 UI 状态层、业务状态层、服务端缓存层。UI 状态层就允许用 setState 或组件级状态，业务状态层放进 Riverpod / Zustand 的 store，服务端缓存则统一走数据请求层，绝不允许业务组件直接改写服务端数据。这样即便工具本身很自由，人的行为也被流程框住了。

另一个值得推广的实践是“状态文件先设计后编码”。RN 项目里，我要求开发者在写页面之前，先花十五分钟把页面涉及的状态写成 TypeScript 接口，定义清楚哪些是局部状态、哪些是共享状态。Flutter 项目里则是先画一小张状态依赖图（不用画得很规范，要素清楚就行），再开始写 Provider 或 Riverpod 的代码。这一步单独看试作时间是增加，但长期看能大大减少后来“无线索状态变更”的排查成本。

4.3 中大型 App：用可测性与责任边界决定架构层级

如果项目已经走到几十个页面、多条业务线并行，我对状态策略的考量顺序是：可测试性、责任边界、性能。Flutter 的大型项目我会偏向 Bloc，因为它的事件渠道天然把所有状态流转变成可追踪的日志，测试时直接注入事件、断言状态就可以；但我不会让所有页面都上 Bloc，而是只让参与复杂业务流的页面走 Bloc，简单页面用本地状态。RN 的大型项目我会偏向 Redux Toolkit，因为单一 Store + 强约束 action 保证了跨模块状态变更有迹可循；同样地，只有跨模块协作的状态才进 Store，纯页面局部状态留在组件内。iOS 原生大项目里，MVVM + Combine、甚至 TCA 在复杂模块里非常有用，但一个模块一旦选用了 TCA，就该整模块统一写法，半 TCA 半 MVVM 的混杂状态是我见过最痛苦的维护现场。

这套“按复杂度分区治理”的思路，和直接用规定好“全项目统一一种状态方案”的做法不同。前者看起来微观上不统一，但宏观上每个区域的复杂度都被控制在合理范围内，反而更可持续。前提是你要在代码评审里把关，不允许任何页面把全局 store 变成垃圾桶。

4.4 踩过的坑：几个值得警惕的反模式

最后分享几个我踩过或者帮别人擦过屁股的反模式，每一条都对应真实的翻车现场。

第一坑：把服务端缓存当成普通 store 来刷。有人把接口返回的数据直接 set 到 Redux/Riverpod 里，然后每个人都在组件里取消或透传刷新，最后状态逻辑深度绑定页面业务，缓存完全无法复用。正确做法是服务端数据单独走一层请求缓存管理，store 里只放业务对缓存结果的引用，别让业务逻辑去摆弄原始数据。

第二坑：在不需要全局状态的地方硬上全局状态全局。我一个朋友做过一个 Flutter 项目，偏偏把每个页面的 loading 状态都放进了全局 Riverpod Provider，结果每次请求都要考虑会不会影响别处刷新的加载动画。老老实实把局部 loading 放在 StatefulWidget 里，别啥都全局化。

第三坑：双端（甚至多端）强行同一套状态策略导致的“进度错配”。有的团队同时有 Flutter 和 RN 项目，非要让两边用同一套状态组织方式，结果不是代码风格统一了，而是所有跨端协作都卡在“为什么 RD 说好的数据结构、RN 这里实现不了”上。跨端团队在状态层可以共享设计原则，但落到具体实现还是别强行一致，否则会浪费掉各个生态的平台优势。

第四坑：忽略持久化。登录态、用户偏好这类需要持久化的状态，如果只放在内存 store 里，冷启动那一刻就会出现空白闪屏或者重复请求。Flutter 用 shared_preferences 或 hydrated_bloc 这类持久化方案，RN 用 AsyncStorage 配合 rehydrate，iOS 用 UserDefaults / SwiftData 早期写入，都要在项目开始时就设计进去，而不是到最后补丁式地加持久化层。

聊到这儿，我其实想收个尾。这几年跨端技术的演化从来没停过：Flutter 的 Impeller 渲染引擎越跑越顺，RN 的新架构在缓慢落地，iOS 每年的系统升级都在把声明式状态管理往前推。我见过太多团队在选型时比照“技术趋势排行榜”，却在半年后发现自己的项目根本不需要那么超前的状态架构。我个人的体会是，状态策略的取舍最终会落到两个朴素的问题上：你的团队能长期维护这套方案吗，以及这套方案能陪你应对到项目变复杂的那个阶段吗？把这两个问题想清楚，用什么库反而只是个执行层面的决定而已。