响应式状态管理是随项目规模演进的思维模式：小状态就地管（useState/ref/setState）、中状态分层控（Context+useReducer/Provider/Pinia）、大状态单向流（BLoC/MVI），选错方案会导致调试难、协作乱、扩展卡。
响应式状态管理不是一套固定工具，而是一套随项目规模演进的思维模式。核心在于：小状态就地管，中状态分层控，大状态单向流。选错方案不只增加代码量，更会埋下调试难、协作乱、扩展卡的隐患。
局部状态：用对基础 API 就够用
计数器、表单输入、开关切换这类仅在单个组件内起作用的状态，无需引入任何库。关键不是“用不用”，而是“怎么用”：
-
React：优先用
useState；对象/数组更新必须创建新引用（如展开运算符），不能直接修改原值 -
Vue 3：基本类型用
ref，对象用reactive；跨组件共享简单状态时，可导出一个reactive对象，但建议封装increment()等语义化方法，避免随意赋值 -
Flutter：用
StatefulWidget + setState；只在 build 中依赖的状态才放在这里，别把网络请求或业务逻辑塞进去
跨层级共享：轻量级响应式方案落地要点
当状态需要穿透两层以上组件（比如主题色、语言、用户登录态），原生 prop 传递就显笨重。此时应转向框架推荐的轻量方案：
-
React Context + useReducer：适合中等复杂度场景；Context 负责透传，
useReducer管理状态变更逻辑；注意避免频繁 Provider 重渲染，可用memo或拆分子 Context -
Flutter Provider：本质是
InheritedWidget的封装；用ChangeNotifier持有数据，调用notifyListeners()触发更新；Consumer 只重建依赖该状态的子树，比全局 setState 更精准 -
Vue 3 Pinia：比 Vuex 更简洁；store 是函数，返回响应式对象；支持模块自动注册、TypeScript 友好、devtools 集成完善；简单项目一个
defineStore就能撑起全局状态
大型应用：单向数据流与可预测性优先
当团队超 5 人、页面超 50 个、状态交互频繁（如表格编辑、实时协作、多端同步），必须放弃“谁都能改”的松散模式，转向结构化架构：
- BLoC（Flutter）：UI 发送 Event → BLoC 处理 → 输出 State；每个状态变化都可追溯来源，配合 DevTools 能完整回放事件流
- MVI（Cycle.js / 类似思想）：Intent（用户意图）、Model（状态转换）、View（纯渲染）三者分离；所有状态变更必须经 Model 流处理，天然支持撤销/重做和时间旅行调试
- Univer 架构（电子表格类应用）：服务（Services）持状态、命令（Commands）改状态、控制器（Controllers）桥接交互；命令即状态变更的“原子操作”，便于日志记录、分布式同步与插件扩展
选型判断：三个问题快速定位方案
面对新项目或重构决策，问自己这三个问题就能避开 80% 的误选：
- 这个状态是否会被 3 个以上不相关的组件读写？→ 否：用局部 API；是：进入下一步
- 状态变更是否需要被审计、撤销、同步到其他设备？→ 否：Provider / Pinia / Context 足够；是：考虑 BLoC / MVI / 命令模式
- 团队是否有能力统一约束状态修改入口？→ 否：优先选语法友好、容错强的方案（如 Pinia）；是：可上强约束架构（如 BLoC）
