多项目间共享Redux逻辑的最佳实践有哪些？

一、核心设计模式 #

• 按业务域封装独立可配置的Redux切片：将通用业务逻辑（比如用户管理、权限校验、通用列表逻辑等）对应的reducer、action、selector按业务域打包为独立模块，对外暴露统一的注册入口和配置参数。比如封装用户模块时支持传入customUserFields、enablePermissionCheck等参数，适配不同项目的差异化需求，无需修改模块内部代码。
• 高阶reducer/工厂函数模式：将分页、异步请求状态管理、筛选排序这类通用逻辑抽离为工厂函数，比如createPaginatedListReducer、createAsyncActionSet，不同项目只需要传入对应业务的action类型、初始状态即可生成适配当前业务的Redux代码，无需重复编写通用的状态更新逻辑。
• 特性开关内置：公共模块中内置特性开关，不同项目引入时可通过配置关闭不需要的功能，避免冗余逻辑被打包进项目。比如精简版项目不需要高级筛选功能，引入切片时传入enableAdvancedFilter: false即可自动裁剪对应action和reducer逻辑。

二、适配工具库 #

• @reduxjs/toolkit（RTK）：Redux官方推荐的工具集，其createSliceAPI天生适合封装可复用的业务切片，配合createAsyncThunk、createSelector可以将完整的业务逻辑封装为独立单元，对外仅暴露切片reducer、预设action和selector，不同项目直接引入注册到自有store即可使用，内置的immer也省去了重复编写不可变更新逻辑的成本。
• RTK Query：非常适配后端共用的场景，可将所有通用接口的请求、缓存、失效、重试逻辑封装为统一的API切片，不同项目直接引入调用即可，完全无需重复编写接口请求相关的action、reducer、loading处理逻辑，差异化需求可通过自定义transform、中间件实现。
• redux-dynamic-modules：支持Redux模块动态加载，不同项目可按需引入需要的公共Redux模块，无需在store初始化时全量注册，还支持模块依赖管理，避免重复注册问题。

三、工程化落地方案 #

• 公共Redux模块和内部UI组件库一起纳入私有npm包管理，独立做版本迭代，bug修复、功能升级仅需更新一次公共包，各项目按需升级版本即可。
• 若使用TypeScript，要为公共模块做好完备的类型定义，对外暴露的配置项、返回值都要有明确的类型提示，避免不同项目接入时出现类型兼容问题。
• 公共模块配套独立的单元测试，保证复用逻辑的正确性，无需各项目重复测试公共逻辑。
• 预留扩展入口：公共模块的action执行前后可注入自定义钩子，selector支持传入自定义转换函数适配不同项目的状态结构需求。

注意事项 #

不要为了复用过度封装，仅抽取多个项目通用的公共业务逻辑，差异化较大的定制逻辑建议保留在各项目内部维护，避免公共包过于臃肿反而提升维护成本。

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