web storage回收需主动干预：localstorage持久但须手动清理，sessionstorage关闭标签页自动释放但需兜底处理；应按场景组合使用、规范命名并设ttl。

Web Storage 的存储空间回收不能靠“等它自己消失”，必须按类型区分干预：localStorage 不会自动清空，sessionStorage 关闭标签页就释放，但两者都需要主动设计回收逻辑，否则容易堆积无效数据、触发容量限制或引发安全风险。

localStorage：持久但需手动“断舍离”

它默认存到用户手动清除或达到浏览器上限（通常 5–10 MB）为止，没有过期机制。长期放任会导致：

• 键名冲突——多个模块用相同 key 覆盖彼此数据
• 陈旧数据残留——比如去年保存的草稿、已弃用的配置项
• 敏感信息滞留——如未加密的 token 或用户标识，存在被窃取风险

推荐做法：

• 写入时嵌入时间戳或 TTL 字段，读取前校验是否过期，过期即自动 removeItem()
• 启动应用时扫描带特定前缀的键（如 draft_、temp_），删除超过 7 天未更新的条目
• 用户退出登录或切换账号时，批量清理关联键（如 auth_*、user_*）

sessionStorage：自动回收≠无需管理

它随标签页关闭自动销毁，看似省心，但仍有隐患：

codex-cn-bridge

一款AI工具，主要用于通过协议转换与自动配置，使 OpenAI Codex CLI 支持多家国内 AI 模型提供商，适合需要提升相关任务效率的用户。

下载

• 页面异常崩溃或强制关闭时，数据可能来不及清理
• 多步骤流程中若中途跳转或刷新，未显式保存的状态会丢失
• 误存长期数据（如用户偏好）导致关闭后体验重置

建议策略：

• 仅用于真正“单次会话内有效”的数据，例如表单第 2 步填写内容、临时筛选条件
• 在 beforeunload 事件中做兜底清理，避免残留脏数据
• 不单独依赖它维持登录态；需要延续的会话，应配合服务端 session 或 localStorage + refresh token

混合使用与降级兼容

单一存储类型无法覆盖所有场景，合理组合才能兼顾安全性、可用性与体验：

• 登录凭证：access_token 存 sessionStorage（防跨 tab 泄露），refresh_token 加密后存 localStorage 并设 7 天 TTL
• 用户偏好：存 localStorage，但监听 matchMedia('(prefers-color-scheme)') 等系统变化，及时同步更新
• 大体积缓存（如离线图片清单、富文本草稿）：改用 IndexedDB，避开 localStorage 容量瓶颈和同步阻塞
• 隐私模式下：部分浏览器禁写 localStorage，应提前检测并 fallback 到内存缓存（Map 或变量）

命名与结构规范，让回收更可控

混乱的 key 命名会让清理变成“盲拆炸弹”。统一规范能大幅降低维护成本：

• 采用作用域+版本+用途前缀，例如 dashboard_v3_sidebar_collapsed、form_draft_contact_2026
• 避免裸键名（如 "theme"），防止第三方脚本或子应用覆盖
• 结构化数据一律 JSON 序列化，封装 safeSet/safeGet 工具函数，自动处理解析失败与空值
• 关键业务升级时，预留迁移逻辑——旧结构数据读取后转换写入新 key，再删旧键