Scalable React应用开发：React.js可扩展状态管理最佳实践有哪些？

以下是经过大量生产项目验证的状态管理常用最佳实践，能够支撑中大型React应用长期迭代的扩展性需求：

• 状态分层管理，避免全局状态滥用
  不要将所有状态都存入全局存储，按场景拆分状态类型处理：
  1. 仅在单个/少数父子组件内使用的本地状态（比如弹窗开关、表单临时输入值），直接使用React原生的useState、useReducer管理即可，不要无意义提升到全局
  2. 跨多模块共享的全局状态（比如用户登录态、全局主题配置）才存入全局状态容器
• 分离服务端状态与客户端状态
  不要把接口请求返回的业务数据硬塞到全局状态里自己维护缓存、更新逻辑，优先使用React Query、SWR这类专门的服务端状态管理库，自动处理数据缓存、请求重试、过期失效、后台刷新等逻辑，能减少90%以上的服务端数据相关样板代码，也避免了手动维护缓存带来的数据不一致问题
• 全局状态按领域拆分，保证粒度足够小
  不要设计大而全的单一全局状态树，按业务领域拆分独立的状态模块，比如用户模块、订单模块、购物车模块各自维护自身的状态和更新逻辑，模块之间互不干扰，既方便后续按模块做代码拆分、按需加载，也能避免单个状态文件体积过大难以维护。如果使用Redux可以用combineReducers拆分，使用Zustand可以直接创建多个独立的store实例
• 优先选择轻量的状态管理方案
  不需要所有项目都上来就引入Redux + 一系列中间件的重方案，针对大多数中大型项目，Zustand、Jotai这类轻量状态库已经足够支撑需求，样板代码少、学习成本低，也能很好的支持状态拆分、持久化等扩展需求
• 复用状态逻辑抽成自定义Hook
  不要在组件内直接写复杂的状态更新逻辑，把可复用的状态相关逻辑封装成独立的自定义Hook，比如useUserInfo、useCart、useSearchFilter，需要用到对应逻辑的组件直接引入Hook调用即可，状态逻辑集中管理，修改时不需要改动多个组件代码
• 严格遵循不可变数据更新原则
  React的状态更新依赖引用变化判断，更新状态时不要直接修改原对象/数组，要么用扩展运算符、数组新方法生成新值，要么引入Immer库，用可变语法编写更新逻辑自动生成不可变数据，能避免大量意外修改状态导致的隐性bug，项目规模越大收益越高
• 路由状态优先存在URL参数中
  页面的分页页码、筛选条件、搜索关键词这类需要持久化、可分享的状态，优先存入路由的search参数中，不需要自己额外维护一份状态再和路由做同步，刷新页面、分享链接都能保留对应状态，也减少了冗余状态带来的同步问题
• 全局状态持久化按需开启
  仅对用户登录态、主题偏好这类长期不变的全局状态做持久化存储（存在localStorage/sessionStorage），不要无差别持久化所有全局状态，避免出现缓存过期、新旧版本数据结构不兼容的问题，做持久化时建议加版本标识，应用版本更新后自动清空旧版本缓存

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