图表编辑应用为用户拖拽元素新增第二个Redux store是否合理？

首先明确结论：这个场景不适合使用多Redux store，不属于多store的合理使用场景，更推荐以下几种更轻量的实现方案

方案1：将拖拽临时态放到组件本地状态/Context管理（最推荐） #

拖拽过程中的实时坐标属于仅用于交互渲染的临时中间态，不需要持久化、不需要全局回溯、也不需要跨多个非关联模块共享，完全没必要走Redux流程：

• 拖拽过程中直接将实时坐标存在拖拽触发组件的本地state，或者专门的拖拽Context中，连线组件同时消费Redux的最终坐标和Context中的临时拖拽坐标做渲染
• 仅在dragEnd事件触发时，将最终坐标dispatch到Redux做持久化更新

这种方案完全不会产生冗余的Redux action，也不需要修改现有Redux的状态结构，改造成本最低。

方案2：现有Redux store新增临时字段，过滤高频action不进历史记录 #

如果你的拖拽状态确实需要被全局多个模块访问，可以直接在现有store的节点结构中增加临时拖拽字段，同时配置中间件过滤这类高频action：

• 给节点增加tmpX、tmpY字段，拖拽过程中dispatch类型为UPDATE_DRAGGING_TMP_POS的action更新这两个字段
• 给你用到的Redux日志、时间旅行、撤销重做等中间件配置过滤规则，直接忽略该类型的action，不会污染历史记录

方案3：分层管理状态，用轻量状态库托管高频交互态 #

如果项目中类似拖拽、画布缩放这类高频交互场景很多，可以用Zustand、Jotai这类轻量状态库单独管理所有交互临时态，和Redux托管的业务持久态分层：

• 所有实时交互的临时状态存在轻量状态库中，无action历史的负担
• 仅在交互结束时，将最终需要持久化的状态同步到Redux中即可

为什么不推荐多store #

Redux官方明确不推荐多store方案，核心问题包括：

• 不同store之间无法天然共享状态，后续如果需要拖拽态和其他业务态做联动，实现成本极高
• DevTools会拆分多份状态历史，调试成本大幅提升
• 原有中间件需要多份实例重复配置，维护成本过高

完全没有必要为了临时拖拽态的场景引入多store的额外复杂度。

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