03-组件通信与状态管理

持久化的难点不是「怎么存」而是「怎么安全地读回来」——因为「你存下去的代码」与「读回来的代码」之间隔着「用户几个月没打开、版本升了 5 次」，所以必须有「版本号 + 迁移链 + 读取时校验 + 失败时降级」这四件套。

赞(0)陌上寒2026-10-13阅读()去评论

跨标签页同步的技术选型是「BroadcastChannel 优先、storage 事件降级、SharedWorker 兜底」，而真正的难点不在「怎么发消息」，而在「回声去重、冲突解决、写放大、以及『只让一个标签页做后台任务』（Leader 选举）」。

赞(0)陌上寒2026-10-13阅读()去评论

有限状态机的价值是「用『显式的状态 + 合法的转移』替代『一堆布尔旗标』」——因为旗标能组合出大量非法状态（isLoading && isError && isSuccess），而状态机只允许穷举出的那几种状态；

赞(0)陌上寒2026-10-13阅读()去评论

Valtio 与 MobX 都属于「代理式响应式（Proxy-based reactivity）」——你「直接改对象」，框架通过「读取时自动追踪、写入时自动通知」算出「谁需要更新」；

赞(0)陌上寒2026-10-13阅读()去评论

Jotai 的模型是「自下而上的原子化状态」——atom 是最小状态单元，派生 atom 用「读取时自动追踪依赖」的方式自动建立依赖图，所以它不需要选择器、不需要 reducer、也不需要「把状态提到顶层」；

赞(0)陌上寒2026-10-13阅读()去评论

客户端状态（UI 状态、用户偏好、本地逻辑）和服务端状态（接口数据）在生命周期与需求上完全不同——后者应该交给 TanStack Query / SWR，而不是塞进 Redux/Zustand；把两类状态混在一起是 React 架构里最常见的错误之一。

赞(0)陌上寒2026-10-13阅读()去评论

Redux Toolkit（RTK）是官方推荐的 Redux 写法——用 configureStore 内置常用中间件、用 createSlice 同时生成 reducer 与 action（并内置 Immer 可直接「改」状态）、用 createAsyncThunk / RTK Query 处理异…

赞(0)陌上寒2026-10-13阅读()去评论

中间件是「在 dispatch 与 reducer 之间插入的一层」，用来处理「非普通对象」的 action（如函数、Promise）或加入横切逻辑（日志、埋点、持久化）；它通过柯里化的函数签名 store => next => action => {} 串联成链。

赞(0)陌上寒2026-10-13阅读()去评论

Redux 用一个单一 store 保存整棵状态树，通过派发 action（描述发生了什么）、由纯函数 reducer 计算新状态来更新——整个流程是单向且可预测的。

赞(0)陌上寒2026-10-13阅读()去评论

先分清「客户端状态」与「服务端状态」——前者用 useState / Context / Zustand / Redux，后者用 TanStack Query / SWR；不是所有共享数据都该进全局 store。

赞(0)陌上寒2026-10-13阅读()去评论