Redux与Context API+useReducer如何选择？百组件React应用状态管理选型问询

2019年之后React生态发生了多次核心迭代，自动批处理、渲染优先级调度等特性大幅弱化了全局状态管理的性能瓶颈，两类方案的适用边界已经和早年的对比结论有明显差异。

核心结论：100-120个组件规模的项目，完全可以仅用Context API + useReducer完成状态管理，Redux不再是必选项，二者选择仅需匹配项目实际场景即可。

优先选择 Context + useReducer 的场景 #

• 状态拆分粒度合理：不将所有全局状态聚合在单个根Context，按业务领域拆分用户态、配置态、业务模块独立态等多个Context，每个Context的Provider仅包裹对应业务域的根组件，而非全量挂载在应用顶层，可规避90%以上的不必要重渲染问题。
• 无复杂异步状态联动需求：如果项目的异步逻辑已经由请求层处理了缓存、重试、请求状态管理，仅存在少量全局同步状态流转需求，Context + useReducer的开发成本远低于Redux，无需引入额外依赖，也无额外模板代码开销。
• 团队熟悉原生React API：你已经掌握Context和useReducer的使用，无Redux相关学习成本，项目迁移进度更可控，120个组件以内的规模只要状态拆分合理，后期维护成本完全可控。

优先选择 Redux（当前推荐 Redux Toolkit/RTK，而非原生Redux）的场景 #

• 存在复杂全局状态逻辑：项目包含大量高频更新的全局状态、跨模块状态联动需求，比如中后台多表单联动、实时协作类应用、需要支持状态时间旅行调试、状态持久化、撤销重做等特性，RTK配套的DevTools可大幅降低这类场景的调试成本。
• 异步逻辑与全局状态强耦合：RTK内置的RTK Query可统一处理数据请求、缓存、失效刷新等逻辑，无需额外引入请求库，整个状态流可实现闭环管理。
• 团队有成熟的Redux使用经验：如果后续维护团队成员普遍熟悉RTK开发模式，也可直接选择，当前RTK已经将早年Redux的模板代码量降低到与Context方案接近的水平，不存在明显的代码冗余问题。

落地建议 #

• 无论选择哪类方案，都不要将所有状态全局化：组件内部状态优先用useState/useReducer，兄弟组件共享状态优先提升至共同父组件，仅跨多层级、跨业务模块的状态才放入全局状态管理，可大幅降低状态管理复杂度。
• 如果对Context方案的性能有顾虑，可配合useMemo、React.memo跳过不必要的重渲染，也可通过状态按需订阅的封装逻辑实现和Redux接近的性能表现。

内容的提问来源于stack exchange，提问作者shrekDeep