在React应用的状态管理中，官方为何不将Context API作为推荐的优先方案？

回答思路

1. 【回答框架 1】React Context API主要用于跨层级传递数据，避免逐层传递props，但其本身并非为高频更新或复杂状态管理设计，在组件树更新时，消费context的组件即使未使用变化部分的数据也可能触发重渲染，导致性能问题。
2. 【回答框架 2】Context API缺乏细粒度的状态拆分机制，多个状态共存于单一context值时，任一变化都会影响所有消费者，难以控制更新范围，相比之下Redux等状态管理库通过selector和订阅机制实现更精确的更新。
3. 【回答框架 3】Context API在代码组织和调试方面存在局限：context值变化难以追踪，Provider嵌套过深时组件结构复杂，且缺少中间件、时间旅行等高级工具，在大型项目中维护成本高。
4. 【回答框架 4】替代方案包括使用useReducer与Context搭配管理局部状态，或引入Redux、Zustand等专门库处理全局状态，以及通过组件组合模式（如children作为props）减少对context的依赖，应根据更新频率、数据规模和团队习惯权衡选择。
5. 【回答框架 5】结论是Context API适合低频、稳定的全局配置（如主题、语言），但高频更新或复杂逻辑场景下，官方推荐结合useReducer或外部状态库，利用其性能优化和可维护性优势。
6. 【关键点 1】Context更新会导致所有消费者组件重渲染，即使它们只使用未变化的部分。
7. 【关键点 2】Context API缺乏选择器机制，难以实现细粒度订阅。
8. 【关键点 3】高频更新的全局状态更适合Redux或Zustand等库，它们提供优化和中间件支持。
9. 【关键点 4】Context适合低频、稳定的全局数据，如主题或用户信息。
10. 【易错点 1】误用Context管理频繁变化的数据，导致性能下降。
11. 【易错点 2】将多个状态合并为一个context值，造成不必要的重渲染。
12. 【易错点 3】忽略消费者组件的memo化，即使使用context也可能引发额外渲染。