上一篇让项目与筛选进入 URL，本篇继续整理任务看板的状态边界。重点不是比较库的热度，而是先给状态分类，再用所有权、更新频率、持久化与一致性要求选择局部 state、URL、Context、外部 store 或请求缓存。
一、痛点：全局状态常是逃避所有权
把所有数据塞进一个 store 看似统一，实际会混合四种生命周期：输入框是否展开是局部 UI 状态；筛选条件是可分享 URL 状态；登录用户是跨树会话状态；任务列表是服务端状态。它们的来源、失效与错误恢复完全不同。若把接口响应复制进 store，更新后既要维护服务器又要维护客户端副本，最容易产生“双重真相”。
状态应放在能覆盖所有消费者的最低公共层。单组件使用useState；多个紧邻组件共享就提升；复杂事件迁移用useReducer；低频跨层数据可用 Context；高频、选择性订阅或框架外访问才考虑 Zustand/Redux 等外部 store。服务器数据交给专门请求缓存，筛选和分页尽量留在 URL。
选型前先为每个值填写五项：权威来源、消费者、写入者、存活时间和恢复方式。selectedTaskId的权威来源是当前浏览器会话，关闭详情即可清理；任务标题的权威来源是服务器，网络失败后应保留旧缓存并重试；筛选的权威来源是 URL，刷新和分享都应恢复。只要这五项清楚，多数值会自然落到合适容器，而不需要争论库排名。
二、原理：用约束矩阵而非品牌选型
Context 解决传递，不自动解决更新性能、持久化和异步竞态。外部 store 的核心价值是独立于组件树的容器与细粒度订阅，但也增加初始化、服务端隔离和调试成本。Redux Toolkit 适合事件审计、严格约定和大型团队；Zustand 适合较薄的客户端共享层；都不是远程缓存的替代品。
还要区分规范状态与派生状态。若已有任务集合和选中 ID，当前任务对象应在读取时查找；若已有单价与数量，总价应计算。重复保存派生值会增加必须同步的路径，任何遗漏都会制造矛盾。只有计算真的昂贵且输入稳定时才缓存结果，而且缓存仍不是新的权威来源。这个“最小充分状态”原则比具体 API 更可迁移。
fromdataclassesimportdataclass@dataclass(frozen=True)classStateNeed:name:strshareable:boolremote:boolconsumers:inthigh_frequency:booldefchoose(need):ifneed.remote:return"query cache"ifneed.shareable:return"URL"ifneed.consumers==1:return"local state"ifneed.high_frequency:return"external store with selectors"return"lifted state or Context"needs=[StateNeed("筛选",True,False,3,False),StateNeed("任务",False,True,4,False),StateNeed("弹窗",False,False,1,False),StateNeed("拖拽坐标",False,False,8,True),]forneedinneeds:print(f"{need.name}:{choose(need)}")运行输出：
筛选: URL 任务: query cache 弹窗: local state 拖拽坐标: external store with selectors三、实现：事件、派生值与选择器
看板只把selectedTaskId和面板模式放客户端 store，完整任务对象仍来自请求缓存。选择器根据 ID 查当前任务；不要同时存selectedTask，否则任务更新后副本过期。动作使用领域语言taskSelected、panelClosed，比裸露setState更容易追踪意图。所有状态更新保持不可变，并为跨请求的 Next.js 服务端渲染创建每请求 store，禁止模块级单例泄露用户数据。
fromdataclassesimportdataclass,replace@dataclass(frozen=True)classUIState:selected_id:int|None=Nonepanel:str="closed"defupdate(state,event):ifevent["type"]=="task_selected":returnreplace(state,selected_id=event["id"],panel="details")ifevent["type"]=="panel_closed":returnreplace(state,panel="closed")ifevent["type"]=="task_deleted":selected=Noneifstate.selected_id==event["id"]elsestate.selected_id panel="closed"ifselectedisNoneelsestate.panelreturnUIState(selected,panel)raiseValueError(event["type"])state=UIState()events=[{"type":"task_selected","id":7},{"type":"task_deleted","id":7},]foreventinevents:state=update(state,event)print(state)运行输出：
UIState(selected_id=7, panel='details') UIState(selected_id=None, panel='closed')订阅外部 store 时选择最小切片。组件只需要selectedId，就不要订阅整个 state；对象选择器若每次返回新对象，需要浅比较或拆成原子选择。派生值应在选择器计算，昂贵计算才缓存。持久化也要克制：主题可以存 localStorage，会话令牌更适合安全 cookie，短暂弹窗状态不该恢复。
动作接口应限制合法迁移。例如详情面板只有taskSelected、panelClosed与selectedTaskDeleted，而不是向任意组件暴露一个接受任意对象的setStore。领域动作让日志可读，也为以后增加撤销、分析或协作同步留下稳定入口。批量更新需要一次事务式动作完成，避免消费者看到“ID 已清空但面板尚未关闭”的中间状态。
在服务端渲染环境，store 生命周期尤其重要。模块级单例会跨请求存活，可能把甲用户的选择泄露给乙用户。应为每个请求创建实例，把必要初值序列化给对应客户端，再在客户端保持稳定引用。若状态完全不影响首屏 HTML，可以延后在浏览器初始化，但要设计一致的占位，避免服务端与客户端首次输出不同。
四、踩坑：持久化与水合会制造新状态
客户端持久化值可能与服务端 HTML 不同，引发水合闪烁。可由 cookie 决定的主题在服务端读取；只能在浏览器读取的值应提供稳定初始值并在挂载后恢复。持久化结构必须带版本与迁移函数，否则一次字段改名就让老用户打不开页面。
不要用 store 绕过组件 API：任何组件都随意写任意字段，会让依赖隐形。限制导出的动作和选择器，开发环境记录事件。也不要为了减少 props 传递两层就引入全局库；显式 props 往往更易复用、测试和服务端渲染。
持久化并非简单调用存储 API。要定义版本号、可持久字段白名单、迁移失败后的安全默认值，以及退出登录时的清理。不要持久化整个 store，因为以后加入令牌或个人数据时很容易被顺手写入磁盘。多标签页是否同步也要显式决定：主题适合同步，未提交草稿可能不适合被另一标签覆盖。
五、验证：测试不绑定实现库
用场景验收：复制带筛选的 URL 后结果一致；选择任务后详情打开；删除当前任务后面板关闭；刷新后只有明确持久化的数据恢复；两个并发服务端请求互不污染。性能测试记录一次拖拽更新影响的组件数，用 Profiler 证明选择器是否有效。
再做一次所有权审计：在开发工具中改变每类状态，观察只有预期消费者更新；模拟旧版持久数据，确认迁移成功或回到安全初值；退出账户后确认个人状态被清除；断网时确认服务器缓存与本地 UI 状态不会互相覆盖。未来替换状态库时，只要动作、选择器和这些场景测试保持不变，迁移就能局限在适配层。
最终状态图应能标出每个值的权威来源、所有者、消费者和清理时机。下一篇将把任务列表正式交给 TanStack Query，处理缓存键、过期、取消、乐观更新和错误回滚，消除手写 Effect 请求的竞态。
参考来源
- React：Sharing State Between Components
- Redux Toolkit：官方文档
- Zustand：官方文档
👍 觉得有用就点个赞 + 收藏，方便回头查阅；有疑问直接在评论区留言，我看到都会回。
🚀 本文属于《现代前端框架实战》系列，持续更新，关注不迷路。
📌 文章里的代码都能直接跑。想要可直接 clone 的完整工程 + 配套部署脚本 / 踩坑清单？评论一声或发邮件到cj2664@qq.com，我免费发你。
如果你正好在做类似系统、或有工程化难题想找人做，也欢迎邮件聊一句——我按实际情况评估，能落地的就接单或出方案。评论和邮件都能直接找到我，不用跳别的平台。
