用途：为 React 应用设计客户端状态架构，并选择合适的状态管理方案。
选型参考：简单共享状态且消费者少于 5 个时用 Context API（零依赖、内置）；中等复杂度且看重性能时用 Zustand（约 1.5kb、无样板代码、自动优化重渲染）；大型应用需要严格模式时用 Redux Toolkit（DevTools、中间件生态、时间旅行）；需要细粒度响应式与原子化时用 Jotai（自下而上、最小重渲染、可组合）；服务端状态（请求与缓存）用 React Query 或 SWR（去重、后台刷新、缓存）。
全局与局部：表单未提交的输入值、UI 状态（开关、hover、focus）、组件级加载/错误状态保留为局部（useState/useReducer）；用户会话与鉴权、主题/语言偏好、3 个以上不相关组件共享的数据、需跨导航保留的状态提升为全局。
状态规范化：把嵌套数据拍平，用 byId 与 allIds 结构存储实体，避免更新复杂度。
乐观更新：先立即更新 UI，出错再回滚。React Query 的 useMutation 可在 onMutate 中取消查询、保存先前数据并写入新数据，onError 回滚，onSettled 使查询失效。
持久化：Zustand 提供 persist 中间件，可指定 name、createJSONStorage(() => localStorage)（或 sessionStorage），并用 partialize 只持久化特定键。
性能：用选择器只订阅所需状态，如 useStore((state) => state.count)；Jotai 用 selectAtom 派生切片；React Query 用 select 只取字段。
性能清单：选择器返回最小必要数据；对昂贵计算做记忆化；按领域拆分 store；Zustand 对象选择使用浅比较；为服务端状态设置合适的 staleTime/cacheTime；避免存储派生状态，从源数据计算。
参考文件包括 zustand-patterns.md、server-state.md、context-patterns.md。
限制：资料未提供具体版本、API 变更说明、适用 React 版本、性能基准或与其他方案的对比结论，暂未提供。