在 React 应用中，引入状态管理器主要为了应对哪些痛点？在哪些业务场景下需要引入状态管理器，哪些场景下则不必？

回答思路

1. 【回答框架 1】状态管理器解决的核心问题是跨组件、跨层级的状态共享与同步，避免通过层层传递 props 或使用回调带来的繁琐和耦合。它提供了全局状态存储和可预测的更新机制，如 Redux 的单一数据源和 action 驱动更新。
2. 【回答框架 2】何时使用：当多个非父子组件需要共享同一份状态，或者状态更新逻辑复杂、需要被多个地方触发时，引入状态管理器能提升可维护性。典型场景包括用户登录信息、购物车数据、全局主题设置等。
3. 【回答框架 3】何时不必：仅局限于组件内部的局部状态，或只需父子间简单通信时，使用 useState、useReducer 或 context 即可满足需求。引入状态管理器会增加样板代码和概念负担，对简单场景反而降低开发效率。
4. 【关键点 1】状态管理器主要解决跨组件通信和全局状态共享的复杂性。
5. 【关键点 2】适用场景：多组件共享状态、状态更新逻辑复杂、需要可预测的状态变更（如 Redux 的 action/reducer）。
6. 【关键点 3】不适用场景：纯组件内部状态或简单父子通信，使用本地状态或 context 更轻量。
7. 【易错点 1】误以为所有共享状态都必须用状态管理器，实际上 context 也可用于中等规模的共享。
8. 【易错点 2】忽略状态管理器带来的学习成本和额外的框架依赖，过度设计。
9. 【易错点 3】混淆状态管理库和 UI 状态，将请求缓存或服务端状态也强行放入全局 store，可能导致性能问题。