用 useReducer 加 Context 复用状态逻辑时，为什么常把 state 和 dispatch 拆成两个 Context？

先用最小代码看清现象

下面的片段只演示“React Context 拆分 state dispatch 性能 复用”最关键的一步。先顺着正常路径读一遍，再改动一个输入，就能直接看到结论在什么条件下成立。

阅读时重点找出哪一行对应“只消费 dispatch 的组件可跳过 state 变化引起的重渲染这一优化动机”，然后观察组件重新渲染次数、状态值、副作用清理和用户界面。这样比从定义开始背更容易留下具体印象。

// 用 useReducer 加 Context 复用状态逻辑时，为什么常把 state 和 dispatch 拆成两个 Context？
// 观察点：只消费 dispatch 的组件可跳过 state 变化引起的重渲染这一优化动机
type State = { count: number }
type Action = { type: 'increment' } | { type: 'reset' }
const reducer = (state: State, action: Action): State =>
  action.type === 'increment' ? { count: state.count + 1 } : { count: 0 }
const [state, dispatch] = useReducer(reducer, { count: 0 })

代码背后的原因

只消费 dispatch 的组件可跳过 state 变化引起的重渲染这一优化动机。示例把这个机制放进了真实的 API、语法或配置中，因此要关注产生结果的操作，而不是把整段代码当成固定模板照抄。

先分清这段逻辑发生在渲染、事件还是副作用阶段，并确认依赖来自哪里。对“只消费 dispatch 的组件可跳过 state 变化引起的重渲染这一优化动机”来说，如果这个条件改变，相同代码可能进入另一条分支、返回不同状态，甚至根本不执行。

放到真实项目里怎么判断

开发模式可能额外执行检查，异步任务也可能晚于组件生命周期结束，代码必须能正确清理和重复执行。验证“只消费 dispatch 的组件可跳过 state 变化引起的重渲染这一优化动机”时先保留正常路径，再增加一个直接相关的反例。一次只改一个条件，才能知道差异究竟来自哪里。

验证“React Context 拆分 state dispatch 性能 复用”不能只看有没有报错，还要检查组件重新渲染次数、状态值、副作用清理和用户界面。涉及资源或异步任务时，也要确认结束后是否正确取消、关闭或释放。

容易答错的地方

记住结论，却忘了前提

只复述“只消费 dispatch 的组件可跳过 state 变化引起的重渲染这一优化动机”仍可能答错，因为它依赖先分清这段逻辑发生在渲染、事件还是副作用阶段，并确认依赖来自哪里。先说适用条件，再说结果。

用一次现象证明所有情况

单次成功只能说明当前输入可用。至少增加一个反例，并检查组件重新渲染次数、状态值、副作用清理和用户界面，才能区分偶然现象与稳定机制。

面试官还会怎么问？

把知识连起来