React 状态持久化深度解析：为何 Redux 与 LocalStorage 必须并存？
在 React 应用开发中，Token 管理是安全与用户体验的核心。许多开发者初期会产生一个疑问：既然已经使用了功能强大的 Redux 进行全局状态管理，为什么还需要手动封装 LocalStorage 操作？本文将从 响应式原理 、Hooks 调用限制 以及 工程化解耦 三个维度进行解析。
一、 内存与磁盘的博弈：响应式 vs 持久化
首先需要明确 Redux 与 LocalStorage 扮演的物理角色：
- Redux (内存状态管理器) ：其本质是驻留在 JavaScript 执行内存（RAM）中的一个对象。它的核心优势在于 响应式（Reactivity）。当 Redux 中的 State 发生变化，React 会自动触发相关组件的重新渲染。
- LocalStorage (磁盘持久化存储) ：它是浏览器提供的 Web Storage API，数据存储在本地磁盘（ROM）中。它的核心优势在于 持久性（Persistence）。页面刷新、浏览器重启，数据依然存在。
为什么不能只用其一？
- 只用 Redux：页面 F5 刷新，JS 引擎重置，内存释放，Token 丢失，用户被迫重新登录。用户体验较差。
- 只用 LocalStorage：数据变动无法驱动视图更新。例如，用户登出后，LocalStorage 已清空，但屏幕上的"欢迎您，xxx"组件因为没有感知到数据变化，依然停留，产生状态不一致的 Bug。
二、 核心限制：为什么不能在非组件文件中使用 useSelector？
这是一个深层次的架构问题：如果我们已经在 Redux 初始阶段读了 LocalStorage，那后续所有逻辑直接通过 useSelector 拿值是否可行？
答案是：Hooks 的调用存在严格的"物理禁地"。
1. 规则约束：Hook 的执行上下文
React 官方规定，Hooks（如 useSelector, useDispatch）必须且只能在以下两个位置调用：
- 函数组件的顶层作用域。
- 自定义 Hook 的内部。
对于普通的 .js 工具文件（如 request.js 请求拦截器、router/index.js 路由配置文件），它们处于 React 渲染调度系统之外。在此类文件中调用 useSelector 会抛出 Invalid hook call 异常。
2. 底层原理：Fiber 节点的锚定
Hook 的运行高度依赖于 Fiber 树的上下文 。当 useSelector 被调用时，React 需要将其关联到当前正在渲染的 Fiber 节点。普通 JS 文件没有 Fiber 标识符，React 无法获取当前的执行上下文。
三、 大厂级架构：Token 持久化链路设计
为了解决上述矛盾，工业级方案通常采用 "单向同步，多点持久化" 的模式。
数据流向分析
后端接口 LocalStorage (硬盘) Redux (内存) 用户 后端接口 LocalStorage (硬盘) Redux (内存) 用户 【登录流程】 【刷新页面流程】 提交账号密码 返回 Token 1. dispatch 存储 Token 2. 同步备份到本地 3. 页面重启，Redux 被清空 4. 初始化前读取备份 5. 恢复 Token 6. 界面保持登录态
四、 为什么需要封装 utils/token.js？
即便逻辑简单，封装一层工具函数也是工程化的必然选择，其价值在于 "低耦合"：
- 集中化 Key 管理 ：全站只需维护一个
TOKEN_KEY常量，避免因拼写错误（如tokenvsTOKEN）导致的逻辑失效。 - 屏蔽底层存储细节 ：如果未来需要将存储介质从
localStorage迁移至Cookie或sessionStorage，只需修改utils/token.js中的内部实现，业务代码无需变动。
五、 总结
在 React 项目中，应当建立如下分工意识：
- Redux 是为了 UI 交互而生的 "快照"。
- LocalStorage 是为了生存而生的 "基石"。
- 封装工具函数 是为了屏蔽存储细节、保证代码健壮性的 "防火墙"。
这种双轨并行的策略，是构建生产级 React 应用的标准范式。