1. useReducer + Context 在中型状态管理的边界（与 Redux 的取舍）
问题
请分析 useReducer + Context 组合在中型应用状态管理中的适用边界，并说明它与 Redux 的取舍？
考察点
- useReducer + Context 的适用规模与局限性
- 与 Redux 在性能、工具链、可维护性上的对比
- 何时该迁移到正式状态库
答案
useReducer + Context 通过 useReducer 管理"状态+更新逻辑"，用 Context 把状态与 dispatch 下发到组件树。它适合状态规模中等、层级浅、更新频率不高的场景，而不引入额外依赖。但 Context 的局限在于：value 变化会使所有消费该 Context 的组件重渲染（即使只依赖其中一部分），缺乏细粒度订阅；且没有中间件、DevTools 时间旅行、持久化等工具链。Redux 则通过订阅机制和 selector 规避了重渲染问题，并提供 DevTools、middleware、持久化等完备生态。取舍的关键是规模与复杂度：小型到中型、状态树扁平、更新不频繁时 useReducer+Context 足够；需要跨模块共享、复杂异步、强调试能力时选 Redux。
解析
核心边界在于"重渲染粒度"与"工程能力"。Context 的 value 变化是整树通知，而 Redux 可精确到单个订阅者。当状态分散、更新频繁、或需要严格的单向数据流治理时，Redux 的收益才超过其样板代码成本。
示例代码
const CountContext = createContext(null);
function reducer(state, action) {
switch (action.type) {
case 'inc': return { ...state, count: state.count + 1 };
default: return state;
}
}
function CountProvider({ children }) {
const [state, dispatch] = useReducer(reducer, { count: 0 });
return <CountContext.Provider value={{ state, dispatch }}>{children}</CountContext.Provider>;
}