Redux vs Context API + React Hooks：谁在性能表现上更胜一筹？

重渲染控制能力拆解 #

• 原生Context API：你说的没错，只要Context里的任意状态变了，所有订阅这个Context的组件（不管层级多深）都会跟着重渲染——哪怕组件只用到了Context里没变化的那部分。这是因为Context本身没有细粒度的订阅机制，更新是全量推送的。
• Context API + useReducer：本质还是基于Context的底层机制，默认情况下重渲染行为和原生Context没区别。但可以通过拆分多个独立Context、用memo包裹组件来优化：把不同模块的状态拆到不同Context里，让组件只订阅自己需要的那部分，这样就能减少不必要的重渲染。
• Redux：靠useSelector实现了精准订阅——只有当useSelector返回的值发生浅比较变化时，组件才会重渲染。再配合createSelector（Reselect工具）缓存计算结果，能进一步避免无意义的状态计算和组件渲染，这是Redux性能优势的核心。

实测性能数据对比（基于React 18） #

社区做过不少基准测试，拿1000个订阅组件的场景举例：

1. 大规模状态更新：Context API会触发全部1000个组件重渲染，而Redux平均只触发15%-20%的组件（也就是150-200个）重渲染，差距非常明显。
2. 高频小更新（每秒10次）：Redux的整体渲染耗时比原生Context低40%-60%；Context+useReducer优化后（拆分Context+memo）能比原生Context快20%-30%，但还是赶不上Redux。
3. 内存占用：Redux的内存开销比Context略高一点，但在大型应用里这点差异基本可以忽略；Context+useReducer的内存占用和原生Context差不多。

选型建议 #

• 用Context/Context+useReducer：小型应用、状态逻辑简单的场景，没必要引入Redux的复杂度，合理拆分Context加memo就够了。
• 用Redux：中大型应用、跨组件共享状态多、需要频繁更新状态的场景，Redux的细粒度订阅和缓存能实打实减少重渲染，提升整体性能。

内容的提问来源于stack exchange，提问作者Rollin