不推荐用 localStorage 直接存储大规模应用状态，应将其作为辅助层精准用于轻量、低频、用户强感知数据，如主题设置、登录标识、表单草稿等，避免存实时状态、敏感信息及大体积数据，并需命名空间隔离、容量管控与内存状态协同。
不推荐用 localStorage 直接存储大规模应用状态。它不是为复杂、高频、实时的状态管理设计的，强行用于主状态容器反而会引发性能卡顿、数据不一致、安全风险和容量溢出等问题。真正有效的优化路径，是把它当作辅助层——精准定位适用场景，分层协同内存状态，而非替代。
明确什么该存、什么坚决不存
localStorage 只适合存轻量、低频变更、用户强感知的数据：
- 用户偏好类：主题色、语言、字体大小、通知开关等设置项
- 登录标识类：access token（需配合 HttpOnly Cookie 做安全兜底）、加密后的 refresh token
- 草稿与临时状态：表单未提交内容、编辑器未保存的序列化 state（如 Lexical 的 EditorState）
- 离线可用片段：静态配置、最近访问路径、带时间戳和版本号的 API 缓存响应
以下内容必须避免存储：
- 实时通信状态（如 WebSocket 连接心跳、消息未读数）
- 频繁更新的 UI 参数（如滚动位置、动画进度、搜索输入实时 debounce 值）
- 完整用户 profile（尤其含手机号、邮箱、地址等敏感字段）
- 嵌套过深或体积过大（JSON.stringify 后超 100KB）的树形结构或列表
强制命名空间隔离 + 结构化键名
多个模块共用 localStorage 容易键名冲突、互相覆盖、清理困难。必须做结构化设计：
- 统一前缀，例如：
myapp:ui:theme、myapp:auth:token、myapp:form:draft_v2 - 按功能域分组，避免平铺式 key（如
theme、token），方便批量操作 - 鸿蒙 ArkTS 环境下，优先使用
@LocalStorageProp绑定页面级状态，而非直接调用原生 API - 跨页面共享时，Web 端用
storage事件监听同步；鸿蒙端用getSharedLocalStorage
容量控制 + TTL 自动清理
5MB 是理论上限，实际可用空间更小。必须主动管控：
- 写入前检查剩余空间，可用
encodeURIComponent(JSON.stringify(localStorage)).length预估占用 - 对大对象做精简：移除 JSON 空格、压缩字段名、只存 diff 而非全量快照
- 所有写入附带时间戳，读取时判断是否过期（如超过 7 天），过期则丢弃并触发重新拉取
- 启动时扫描特定前缀（如
myapp:temp:），自动清理陈旧条目
与内存状态协同，而非替代
localStorage 永远不应是唯一状态源。正确协作方式如下：
- 应用启动时，从 localStorage 读取可恢复项（如 theme、draft），合并进内存 store（Pinia / Zustand / ArkTS @State）
- 状态变更后，异步且防抖写入（debounced），不阻塞主流程
- 登出、切换账号等敏感操作，立即清空对应命名空间下的所有 key
- 对关键状态（如 token）做双重校验：内存中存在 + localStorage 中有效，任一缺失即重置
不复杂但容易忽略。
