Context API适合低频更新、小范围共享的数据，如主题和登录态；Redux适合中大型应用中频繁变化、逻辑复杂、需调试和时间回溯的状态流。
Redux 和 Context API 都能管理跨组件的状态，但定位和适用场景很不同：Context API 适合低频更新、小范围共享的数据（比如主题、用户登录态）；Redux 更适合中大型应用中频繁变化、逻辑复杂、需要调试和时间回溯的状态流。
Context API：轻量、简单、适合局部状态共享
它本质是 React 内置的“数据透传”机制，不自带状态管理逻辑，需要配合 useReducer 或 useState 才能真正管理状态。没有中间件、没有时间旅行、也没有 Redux DevTools 支持。
- 适合场景：用户偏好（暗色模式）、认证信息、语言设置等更新不频繁、组件树不深的数据
- 注意性能：Context 的值一旦改变，所有 useContext 的组件都会重新渲染——即使它们只用其中一小部分字段
- 优化方式：拆分多个 Context，或用 useMemo 包裹 provider 值，避免无谓重渲染
Redux：功能完整、可预测、适合复杂状态流
它是一个独立的状态管理库，强制使用单一数据源、纯函数 reducer、不可变更新，并通过 store 统一调度。配合 Redux Toolkit（RTK），写法已大幅简化。
- 核心优势：强大的开发者工具（action 日志、状态快照、时间回放）、中间件支持（如异步处理 thunk / saga）、易于测试和协作
- 适用场景：多模块交互（购物车+订单+库存联动）、需撤销/重做、API 请求状态管理、权限动态变化等
- 代价：额外学习成本、少量样板代码（即使用了 RTK）、轻微运行时开销
选哪个？看实际需求，不是越重越好
新项目别一上来就配 Redux。先用 Context + useReducer 解决登录态或主题切换；当发现状态逻辑开始散落在多个组件、reducer 越来越长、调试困难、多人协作常踩坑时，再迁移到 Redux Toolkit。
立即学习“Java免费学习笔记（深入）”；
- 小应用 / 页面级状态 → useState 或 useReducer 就够了
- 跨层级共享 + 更新少 → Context API 是更自然的选择
- 状态多、变化频繁、需可观测性 → Redux Toolkit 是更稳妥的方案
基本上就这些。两者不是替代关系，而是互补：Context 做“传递”，Redux 做“管理”。用对地方，都挺好。
