4. 状态管理方案对比与选型：Redux、MobX、Zustand、Context 的异同与项目侧重点

面试问题：请对比 Redux、MobX、Zustand 和 Context 的核心区别，以及你会怎样选型？

面试官考察点：①是否理解不同方案的设计哲学；②能否从业务场景出发做技术决策；③是否关注性能、TS 兼容、调试工具等工程因素。

回答框架：按“维度对比 → 适用场景 → 选型结论”三步。维度包括：数据流方式（单向/双向）、渲染粒度、样板代码量、TS 支持、中间件/调试生态。

简短示例回答：Redux 单向流 + 不可变数据，适合复杂状态逻辑和大型团队；MobX 响应式代理，代码简洁但调试依赖堆栈；Zustand 轻量 Hook 驱动，TS 友好，适合中小组件库；Context 适合低频全局主题，高频更新需配合 useMemo 避免重渲染。

可能追问：①Redux 的 Immer 中间件原理？②Zustand 的 subscribe 如何精确控制渲染？③Context 的 value 不变时子组件会重渲染吗？

面试问题：在什么场景下你会用 Context 替代 Redux？用 Context 有什么潜在风险？

面试官考察点：①对 React 渲染机制的理解；②能否识别 Context 的局限性；③是否有实际重构经验。

回答框架：“场景判断 → Context 优势 → 风险点 → 补偿措施”。优势：零依赖、简单、与 React 组合模式自然。风险：value 变化导致所有 consumer 重新渲染（除非 memo），难以跟踪变化来源，无中间件。

简短示例回答：我会在只有少数几个全局状态（如语言、主题）且更新频率低的场景用 Context。若状态更新频繁或需要中间件（如埋点、持久化），则用 Redux Toolkit + configureStore 提供 devTools 和 middleware 支持。Context 的风险是深层组件无法跳过父级渲染，我用 useMemo 包裹 value 并拆分 Context。

可能追问：①如何用 useMemo 优化 Context value？②如何实现类似 Redux middleware 的 Context 增强？③为什么不直接用 useState + 透传？

面试问题：你在实际项目中使用过 Zustand 吗？相比 Redux 它解决了哪些痛点？

面试官考察点：①是否有真实落地经验；②能否客观评价工具局限；③是否了解 Zustand 的底层实现（如使用 useSyncExternalStore）。

回答框架：“项目背景 → 痛点对比 → 解决效果 → 注意事项”。痛点：Redux 样板代码多、学习曲线陡、模块拆分成本高。Zustand 通过 create 生成 store，天然支持 TS，selector 自动浅比较，无需 Provider 包裹。

简短示例回答：在后台管理系统的权限模块中，我使用 Zustand 替代 Redux。之前 Redux 需要定义 actions、reducers、types 三件套，Zustand 只用一个 create 函数，配合 immer 中间件实现可变写法，开发效率提升 40%。同时 Zustand 的 subscribe 可以精确订阅某个字段，避免无关组件重渲染。

可能追问：①Zustand 的中间件机制如何实现？②如果项目后期需要 Redux devTools，Zustand 是否兼容？③当状态间有复杂依赖时你会怎么拆分 store？