面试题答案
一键面试数据流向
- useContext：数据流向较为简单直接，通过上下文（Context）传递数据，组件树中任何层级的组件都能直接获取到上下文数据，没有中间处理环节，但缺乏明确的数据流动轨迹追踪，不利于调试复杂场景。
- Redux：采用单向数据流，数据从 store 流向 view，用户交互产生 action，action 被 reducer 处理后更新 store，再重新渲染 view，数据流动清晰，便于调试和理解。
- MobX：数据流向相对灵活，它基于响应式编程，当数据发生变化时，与之相关的视图会自动更新，虽然能高效更新视图，但数据变化的追踪相对复杂，不如 Redux 单向数据流直观。
性能表现
- useContext：性能依赖于上下文变化的频率。如果上下文频繁变化，会导致订阅该上下文的所有组件重新渲染，可能影响性能；但如果上下文数据变化少，性能消耗相对较小。
- Redux：由于采用单向数据流，每次 state 更新都可能导致整个应用重新渲染（虽然可以通过 shouldComponentUpdate 等手段优化），在大型应用中频繁更新 state 可能会有性能问题。不过，结合 Redux - Thunk、Redux - Saga 等中间件处理异步操作时，处理得当性能也能保证。
- MobX：基于响应式编程，只有依赖数据发生变化的组件才会重新渲染，性能表现通常较好，尤其是在应用中有大量相互关联数据，且部分数据更新频繁的场景下，优势明显。
代码复杂度
- useContext：代码相对简单，只需创建上下文并在需要的组件中消费即可，无需引入过多额外概念和代码结构。但对于复杂的状态管理逻辑，仅靠 useContext 实现会导致代码逻辑分散在各个组件中，难以维护。
- Redux：代码复杂度较高，需要定义 store、action、reducer 等多个概念和文件，文件结构相对复杂。特别是在处理异步操作时，还需引入中间件，进一步增加代码量和复杂度。
- MobX：代码复杂度介于两者之间，定义 observable 数据和 action 相对简洁，但响应式编程的概念对于初学者可能较难理解，并且在大型项目中，数据依赖关系的管理也有一定难度。
可维护性
- useContext：简单场景下可维护性好，代码直观。但随着应用规模扩大，状态管理逻辑分散，难以追踪数据变化和调试，可维护性变差。
- Redux：虽然初始代码结构复杂，但单向数据流和明确的状态更新规则使得代码可维护性在大型项目中表现良好，便于团队协作开发和后期维护。
- MobX：依赖关系自动管理在一定程度上提高了可维护性，但复杂的响应式逻辑和数据依赖关系可能使代码难以理解和维护，尤其对于不熟悉响应式编程的开发者。
优先选择 useContext 的业务场景
- 简单小型应用：应用规模较小，状态管理需求简单，数据共享层级不多，此时使用 useContext 能快速实现全局状态管理，代码简洁，开发效率高。
- 局部组件树状态管理：在应用中某部分组件树需要共享状态，且该状态与其他部分关联性不强，使用 useContext 可以将状态管理限制在局部，避免引入 Redux 或 MobX 的复杂性。
- 对性能要求不高且追求简单实现：如果应用对性能要求并非极其严格，且希望以最简单方式实现全局状态管理，useContext 是不错选择，无需学习复杂的状态管理库。