前端状态管理方案选型：从 Context 沦陷到 Zustand 迁移的决策框架
一、Context 性能陷阱的爆发时机
用 React Context 做全局状态管理是许多项目的起点。在用户量低于 1000、状态树少于 10 个字段时，Context 工作良好。但当 Dashboard 页面同时管理用户信息、主题配置、通知列表、筛选条件四个 Context 时，问题开始显现。
具体表现为：修改通知列表中的一条未读标记，导致整个 Dashboard 树重新渲染。排查后发现，NotificationsContext 的 value 是一个包含{list, unreadCount, filter}的对象，更新 list 中某一项的 read 状态时，新的对象引用触发了所有 useContext 的消费者重新渲染，即使某个消费者只关心 unreadCount。
这种"一个字段变化、全局重新渲染"的行为是 Context 的固有特性，不是 Bug。它的触发不需要状态树特别大——当 Context 数量从 3 个增长到 6 个以上时，渲染性能下降的体验就可见了。
二、三种方案的渲染粒度对比
不同状态管理方案的核心差异在于"谁能决定何时重新渲染"。下面的 Mermaid 图展示了一棵组件树在状态变化时的更新范围：
graph TB subgraph Context方案 C1[Provider → 整个子树重渲染] end subgraph Zustand方案 Z1[Store 原子选择器] Z1 --> ZA[组件 A：订阅 name] Z1 --> ZB[组件 B：订阅 count] Z1 --> ZC[组件 C：不订阅] ZA -.->|name 变化时重渲染|ZA ZB -.->|count 变化时重渲染|ZB end subgraph Jotai方案 J1[name atom] J2[count atom] J1 --> JA[组件 A：订阅 name atom] J2 --> JB[组件 B：订阅 count atom] JA -.->|name atom 变化时重渲染|JA JB -.->|count atom 变化时重渲染|JB endContext 的问题在于 Provider 值变化会通知整棵子树。Zustand 使用选择器让组件精确声明自己依赖的状态字段，不相关字段变化时不触发重渲染。Jotai 更进一步将状态拆分为独立原子，天然具备最细粒度的更新。
三、状态迁移的四步渐进策略
从 Context 迁移到 Zustand 不应是一次性的大重构。在一周内改 80 个文件必然引入回归 Bug。推荐按状态的数据特征分四步渐进迁移：
第一步：隔离服务器状态。将用户信息、列表数据、详情等来自 API 的数据迁移到 TanStack Query 管理，Context 中只保留 UI 状态。这一步不改变状态库，但能立即减少 Context 的更新频率。
第二步：迁移高频更新状态。将通知列表、搜索关键词、表单草稿等高频变化的字段迁到 Zustand。这些字段是 Context 的性能杀手。
第三步：迁移跨页面共享状态。主题配置、语言偏好、登录态等全局状态也迁到 Zustand，它们的特点是跨路由保持。
第四步：清理 Context 残留。前三步完成后，Context 中应该只剩下纯粹的组件局部状态，如果还有则审视是否应改为 props 传递。
// 迁移示例：将通知状态从 Context 拆分为独立的 Zustand Store import { create } from 'zustand'; interface Notification { id: string; title: string; read: boolean; createdAt: number; } interface NotificationState { list: Notification[]; unreadCount: number; // 单项更新——只触发订阅 list 中该项的组件 markAsRead: (id: string) => void; // 批量更新——用于"全部已读"操作 markAllAsRead: () => void; // 添加新通知时自动更新未读数 addNotification: (item: Notification) => void; } export const useNotificationStore = create<NotificationState>((set, get) => ({ list: [], unreadCount: 0, markAsRead: (id: string) => { // 设计意图：不可变更新，使用 immer 风格的 set // 仅更新 list 中匹配 id 的那一项 set((state) => { const list = state.list.map((item) => item.id === id ? { ...item, read: true } : item ); return { list, unreadCount: list.filter((item) => !item.read).length, }; }); }, markAllAsRead: () => { set((state) => ({ list: state.list.map((item) => ({ ...item, read: true })), unreadCount: 0, })); }, addNotification: (item: Notification) => { // 维护未读数，保证数据一致性 set((state) => ({ list: [item, ...state.list], unreadCount: state.unreadCount + (item.read ? 0 : 1), })); }, })); // 消费端：精确订阅，避免无关渲染 function NotificationBadge() { // 只订阅 unreadCount——list 变化不会触发此组件渲染 const unreadCount = useNotificationStore((s) => s.unreadCount); if (unreadCount === 0) return null; return <span className="badge">{unreadCount}</span>; } function NotificationItem({ id }: { id: string }) { // 订阅单条通知——其他通知的状态变化不影响此组件 const item = useNotificationStore((s) => s.list.find((n) => n.id === id) ); const markAsRead = useNotificationStore((s) => s.markAsRead); if (!item) return null; return ( <div className={item.read ? 'read' : 'unread'} onClick={() => markAsRead(id)} > {item.title} </div> ); }选择器函数的粒度决定了渲染性能。useNotificationStore((s) => s.list)会在任何通知变化时重渲染，更优的做法是只订阅当前组件关心的单条数据。
四、方案选择的决策矩阵
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 服务端数据（列表/详情） | TanStack Query | 自动缓存、去重、重新验证 |
| 全局 UI 状态（主题/语言） | Zustand | 跨路由持久化，选择器精确订阅 |
| 表单草稿/搜索关键词 | Zustand 或 Jotai | 高频更新但更新范围可控 |
| 组件间短期共享状态 | Jotai | 原子化管理，组件卸载自动清理 |
| 复杂工作流编辑器状态 | Zustand + Immer | Immer 简化不可变更新 |
| 需要时间旅行调试 | Zustand + Devtools | 中间件支持 |
Zustand 和 Jotai 的选择分界线：需要将状态"组合和派生"的场景用 Zustand，需要状态"按原子隔离"的场景用 Jotai。实际项目中选择一个并坚持用到底，混用会增加学习成本。
五、总结
状态管理迁移的核心原则：
- 先区分服务器状态和 UI 状态，前者交给缓存方案；
- 按状态更新频率优先迁移高频状态，低频全局状态可后置；
- 选择器订阅粒度决定渲染性能——避免订阅不需要的字段；
- 一个项目中坚持一种主方案，避免 Zustand + Jotai + Redux 三套并存。
渐进迁移四步走：
- 服务器状态迁移到 TanStack Query；
- 高频 UI 状态迁移到 Zustand；
- 跨路由全局状态迁移到 Zustand；
- 清理 Context 中的局部状态残留。
