如何在导出复用组件的npm模块中实现React状态管理

你的场景核心是组件库自带高复杂度共享状态、需要做状态分层（大部分私有不对外、少部分对应用开放）、同时支持宿主应用触发状态修改，下面是生产环境验证过的可行方案，按适配度从高到低排序：

方案1：Redux Toolkit 构建隔离式独立Store（高复杂度状态首选） #

这个方案最适合状态逻辑复杂、需要中间件、状态追溯能力的场景，完全不会和宿主应用的状态冲突：

• 组件库内部用@reduxjs/toolkit封装专属store实例，不要依赖宿主应用传入Redux Provider，从根源上避免和应用自身的Redux状态命名、逻辑冲突。
• 按访问权限拆分slice做状态分层：
  • 私有状态：单独存放在内部slice，相关的选择器、action全部不对外导出，组件库内部封装专属的useLibSelector、useLibDispatch钩子供库内组件读写，宿主应用完全感知不到这部分状态的存在。
  • 公开状态：单独拆分public slice，仅将这部分状态的读取选择器、允许外部触发的action对外导出。
• 宿主应用接入逻辑：
  • 默认场景下直接导出库内封装好的dispatch方法，应用调用即可触发开放的action修改内部状态；
  • 如果宿主应用本身也使用Redux，可以额外提供reducer注入工具，支持应用选择性将public slice挂载到自身store上实现状态同步，不挂载也不影响组件库正常运行。
• 注意要在组件库最外层套上自带的StoreProvider，所有库内组件都包在这个Provider内部，不需要应用做额外的Provider配置。

方案2：React Context + useReducer 实现（中等复杂度状态适用） #

如果不想额外引入Redux依赖，这套方案足够覆盖需求，打包体积更小：

• 在组件库内部通过React.createContext创建专属上下文，上下文 value 存useReducer生成的state和dispatch方法，所有库内组件都包裹在自定义的Context Provider下。
• 同样做分层逻辑：
  • 私有状态对应的action、读取逻辑全部封装在库内部的自定义hook中，不对外导出；
  • 仅将公开状态的读取hook、dispatch方法对外导出，比如useLibPublicState、useLibDispatch，宿主应用直接调用这两个钩子就能读取公开状态、触发允许的状态修改。
• 性能优化点：高频更新的状态不要全部塞到同一个Context里，按更新频率拆分多个Context，或者引入use-context-selector做细粒度订阅，避免组件树不必要的重渲染。

方案3：Zustand 单例Store（轻量场景首选） #

如果状态复杂度没到需要Redux全链路能力的程度，这个方案实现成本最低、性能表现好：

• 组件库内部用Zustand创建独立的store单例，不需要额外包裹Provider。
• 状态分层通过控制导出粒度实现：
  • 私有状态的读写逻辑封装成库内部使用的hook，不对外暴露；
  • 仅导出允许应用访问的状态选择器、状态修改方法，应用直接调用导出的方法就能修改内部状态、订阅公开状态变化。
• 这套方案包体积极小，不需要处理Provider嵌套、多store冲突问题，大部分内部组件库场景用这个足够。

通用注意事项 #

• 严格控制公开状态和公开action的边界，不要随意把内部状态暴露出去，不然后续调整内部逻辑很容易出破坏性变更，影响接入应用。
• 对外暴露的状态修改入口一定要做参数合法性校验，避免应用传入非法值搞乱组件库内部状态。
• 如果需要支持同一页面挂载多个组件库实例的场景，不要用全局单例store，改成Provider注入store实例的模式，避免多实例之间状态串扰。

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