Context API 是数据传递机制而非状态管理库，Redux 是独立状态容器；中等复杂度场景优先用 useContext + useReducer，仅在需调试、持久化等时选 Redux。
Redux 和 Context API 都能管理状态，但不该混用“状态管理”这个说法去模糊它们的定位差异：Context API 是 React 的数据传递机制，不是状态管理库；Redux 是独立的状态容器，自带可预测更新、中间件、时间旅行等能力。选哪个，取决于你是否真的需要它。
什么时候该用 useContext + useReducer 而不是 Redux
大多数中等复杂度的组件树（比如用户登录态、主题切换、表单全局配置）用 useContext 配合 useReducer 完全够用，且无额外依赖。
- 状态变更逻辑集中、不跨多个异步来源（如 WebSocket + API + localForage 同时触发更新）
- 不需要调试工具（Redux DevTools）、持久化（
redux-persist）或服务端渲染时的初始状态注入 - 没有团队协作强约束（比如要求所有状态变更必须带 type 字符串和 payload 结构）
const ThemeContext = createContext();
const themeReducer = (state, action) => {
switch (action.type) {
case 'TOGGLE': return { ...state, dark: !state.dark };
default: return state;
}
};
function ThemeProvider({ children }) {
const [state, dispatch] = useReducer(themeReducer, { dark: false });
return (
<ThemeContext.Provider value={{ state, dispatch }}>
{children}
</ThemeContext.Provider>
);
}
Redux Toolkit 的 createSlice 和 Context 的 reducer 写法区别在哪
表面看都是“reducer + action”，但 Redux Toolkit 强制结构化、自动绑定、生成 action creator，而 Context 下的 reducer 是纯函数，需手动构造 action 对象。
-
createSlice自动生成actions对象和reducers映射，支持prepare回调处理 payload 格式 - Context 中的 reducer 没有 action type 命名空间隔离，容易命名冲突；Redux 默认加前缀（如
theme/toggle） -
createSlice返回的reducer可直接传给configureStore；Context 的 reducer 必须配合useReducer使用，无法复用到非 React 环境
性能陷阱：Context 不是“低配 Redux”，它会引发不必要的重渲染
Context 的本质是订阅机制，只要父级 Provider 的 value 引用变了，所有消费组件都会 re-render —— 即使只用了其中某个字段。
立即学习“Java免费学习笔记（深入）”；
- 避免把整个 state 对象直接塞进
value，改用多个细粒度 Context（如UserContext、ConfigContext） - 不要在
value中写内联对象或函数：value={{ user, updateUser: () => {} }}→ 每次渲染都新建对象，触发下游重绘 - 用
useMemo缓存value，或拆出自定义 Hook 封装useContext+useSelector类似逻辑（但别叫它 useSelector）
错误信息 Could not find the context value 的真实原因
这不是 Context 没导出，而是组件没被对应 Provider 包裹，或者包裹层级错了。React 18 严格模式下尤其明显。
- 检查组件是否在
<MyContext.Provider>内部，而不是兄弟节点或外部 - 确认 import 路径一致：同一 Context 对象不能从两个不同路径 import（比如
./contextvs../context） - 如果是动态导入（
React.lazy），Provider 必须在 Suspense 外层，否则 fallback 期间 context 为空 - 不要在自定义 Hook 里直接调用
useContext后返回 JSX —— 这会让调用方误以为 Hook 自动提供上下文
真正难的从来不是“怎么写”，而是判断“要不要写”。Redux 的 setup 成本、学习曲线、bundle 体积增量，对多数业务模块来说是负收益。Context 的轻量是优势，也是陷阱——它太容易被滥用成“全局变量传送带”。状态到底该提升多高、拆多细、是否要序列化、谁负责清理副作用，这些设计权衡不会因为选了某个方案就自动消失。
