Redux开发：超4000个值的大型状态用单Reducer还是多Reducer？

当你的Redux状态包含4000+值的超大规模数据时，拆分状态用多个Reducer分别维护是更合理的选择，原因如下：

• 可维护性碾压单Reducer
  4000+值的状态如果塞进单个Reducer，代码量会爆炸，几百上千行的switch case和状态处理逻辑混在一起，找个action对应的修改逻辑都要翻半天，后期改bug、加新功能简直是灾难。拆分后每个Reducer只负责一块业务相关的状态，比如用户信息、商品列表、系统配置各用一个Reducer，职责清晰，谁维护哪块一目了然，代码可读性和可维护性直接拉满。

• 性能优化更精准
  Redux的combineReducers会自动对每个Reducer返回的状态做浅比较，只有当前Reducer负责的状态块变化时，依赖这块状态的组件才会重渲染。如果用单个Reducer，任何一个小值的修改都会触发整个状态的更新，所有依赖全局状态的组件都可能跟着重绘，4000+值的场景下，这种不必要的重渲染会带来巨大的性能开销。另外，拆分后还能配合reselect针对性地缓存衍生数据，进一步减少不必要的计算。

• 团队协作更顺畅
  多人开发时，单个Reducer很容易出现代码冲突，大家都在同一个文件里改逻辑，合并代码时头疼不已。拆分后每个人负责自己的Reducer模块，并行开发互不干扰，冲突概率大幅降低，协作效率直接提升。

当然也有极端例外：如果这4000+值是完全同构的集合（比如结构一致的超大数组），且所有更新逻辑完全统一，那单个Reducer可能更简洁，毕竟没必要写一堆重复逻辑的Reducer。但这种场景非常少见，绝大多数业务场景下，数据都是分模块、有不同业务逻辑的。

拆分Reducer时记得遵循单一职责原则，按业务模块、数据类型划分边界，不要为了拆分而拆分，也不要把关联紧密的状态拆得太碎。

内容的提问来源于stack exchange，提问作者Yunus Emre Arslan