第 5 章 状态管理与数据流
第 5 章 · 状态管理与数据流
章节摘要：本章回答"数据从哪来、存哪里、怎么更新"这个从能写界面到能写产品的核心问题。RN 侧从 useState、useReducer 到 Context，Flutter 侧从 setState、InheritedWidget 到 Provider；再到两套框架各自的全局状态管理方案对比与生命周期管理。读完本章，你将能系统设计应用的数据流，而不是把状态随手乱放。
阅读收获
阅读完本章，你应当能够：
- 用 useState 与 useReducer 管理 RN 组件内部状态，并说清两者的适用边界（简单值用前者，复杂更新逻辑用后者）。
- 理解 Context 与 InheritedWidget 在跨组件共享数据中的角色，并说出它们各自的原理。
- 对比 RN 的 Redux、Zustand 与 Flutter 的 Provider、Riverpod 等状态管理方案，能按项目规模做选择。
- 理解组件生命周期与副作用管理（Hooks 与 Widget 生命周期方法），知道副作用该在哪个时机执行。
- 为"状态放组件内部还是全局"做出合理判断，并解释判断依据。
核心概念速览
一句话点题：状态管理的本质是回答"这个数据该由谁拥有"。想清楚归属，方案自然选对；方案之争，多数是归属不清。
子章节导航
5.1 React Native 组件内部状态
从 useState 讲到 useReducer，再到 Context。这一节建立 RN 状态管理的基础阶梯：先学会"组件自己的状态放组件里"，再学会"跨组件共享用 Context"。
这三个概念是层层递进的：useState 管最简状态（一个值），useReducer 管复杂状态逻辑（多个操作、多个关联值），Context 解决"数据要穿过多层组件传递"的痛点。多数新手把三者混为一谈，其实它们是三个不同层级的问题。读这节时建议带着问题：我的状态是"一个值、一组操作、还是要全局共享"？答案对应不同的工具。
5.2 Flutter 的 setState 与 InheritedWidget
对应 RN 那套基础，Flutter 用 setState 管组件内部状态，用 InheritedWidget 实现跨组件共享。这一节讲清两套机制的原理与用法，为后面的 Provider 做铺垫。
setState 在第 3、4 章已经多次出现，本节把它讲透：为什么必须包在 setState 里、什么时候会触发重建、性能影响是什么。InheritedWidget 是 Flutter 的"隐式数据传递"机制——数据挂在树上，子树里的任意组件都能读取，不用逐层传参。它是 Provider 的底层实现，理解它才能理解 Provider 为什么存在。
5.3 常用状态管理方案对比
状态复杂到组件内部装不下时，需要全局方案。RN 侧看 Redux、Zustand、MobX，Flutter 侧看 Provider、Riverpod、Bloc。这一节不吹不黑，讲清各方案的取舍与适用场景。
这一节是全章最容易"挑花眼"的地方——方案太多，每个都有拥护者。我的建议是：先别急着站队，把每个方案的"核心主张"和"代价"看清楚。比如 Redux 主张单向数据流与可预测性，代价是样板代码多；Zustand 主张极简 API，代价是约束少、团队需要自律。方案没有绝对好坏，只有适不适合你的项目规模与团队习惯。
5.4 组件生命周期与副作用管理
RN 的 useEffect 与类组件生命周期，Flutter 的 initState、didUpdateWidget、dispose 等方法。这一节讲清"什么时候该做什么"，以及如何在正确时机执行副作用（网络请求、订阅、清理）。
生命周期是状态管理里最容易被低估的部分。很多 bug 的根源不是"状态没管好"，而是"副作用在错误时机执行"——比如在渲染里发网络请求、忘记清理订阅导致内存泄漏。这一节会建立一张"生命周期时间线"，把创建、更新、销毁三个阶段的正确动作理清楚。RN 与 Flutter 的时间线大同小异，掌握了时间线的形状，两套框架只是方法名不同。
子章节之间的逻辑关系
5.1 与 5.2 是并行基础，分别建立两套框架的状态管理起点；5.3 是进阶——状态复杂时怎么选全局方案；5.4 是贯穿性主题——无论局部还是全局，都要理解生命周期与副作用。顺序是"管局部 → 管全局 → 管时机"。
这套结构背后有一个值得记牢的判断流程：写界面时先问"状态属于谁"——只属于当前组件就放组件内部（useState、setState），需要跨组件共享就上 Context 或 InheritedWidget，共享范围很大、更新频繁就考虑全局方案（Redux、Provider 等）。把"归属"想清楚，方案选择就顺理成章。5.4 的生命周期则是所有方案都要遵守的"时间纪律"——状态在什么时机初始化、什么时机清理，决定了应用的健壮性。
5.1 RN 局部状态 ──► 5.3 全局方案对比（RN 侧） │ 5.2 Flutter 局部状态 ─┘ │ └► 5.4 生命周期与副作用
关于本章的学习方法
状态管理是最容易"看懂但不会用"的一章。看懂概念只需要理解几个方案的主张，会用则需要把"状态归属判断"练成习惯。本章提供一个贯穿性练习：把第 4 章的待办页面在 5.1/5.2 节各做一遍局部状态版，到 5.3 节再升级一个全局状态版，最后在 5.4 节为它补上生命周期管理（加载、清理）。同一个页面反复打磨四遍，状态管理的每个层次都会在你手里过一遍——这比读十个方案的对比文章有效得多。判断本章是否掌握，不看记住了几个方案名，而看能不能说清"这份数据该由谁拥有、怎么更新、何时清理"。
前置知识与后续延伸
- 前置知识：第 3 章的声明式思想（UI 是状态的函数）与第 4 章的组件体系。理解"状态驱动界面"，才能理解状态管理为什么重要。第 4 章的待办页面是本章练习的最佳起点。
- 后续延伸：本章的状态方案是第 6 章所有功能（导航传参、网络数据、本地存储）的数据底座。把第 4 章的待办页面升级为"状态管理完整版"（支持全局共享、正确清理资源），正是本章最合适的练习。学完第 6 章后，这个待办应用就可以加上网络请求与本地持久化，成为一份完整的个人项目作品。