Web Storage 清理必须主动设计而非依赖自动机制：localStorage 永不过期，需在登出、版本升级、读取过期时及用户手动操作时清理；sessionStorage 虽绑定标签页，但需在 beforeunload、路由跳转、跨标签场景下兜底清理；跨标签页应结合 storage 事件与状态管理协同同步与清理。
Web Storage 的清理不能靠“等它自己消失”，必须按场景主动设计清理时机。localStorage 永不自动过期，sessionStorage 虽然关闭标签页就清空，但刷新、多标签、页面异常退出等情况仍可能留下无效数据。关键不是“要不要清”，而是“什么时候清、怎么清更稳妥”。
localStorage：持久存储≠永久有效，需分场景设清理点
它不会随浏览器重启消失，但业务逻辑常有明确的失效边界：
- 用户主动登出时：清除 token、权限标识、临时缓存等敏感或会话相关数据，避免残留导致越权或状态错乱
- 版本升级或配置变更后：比如前端发版、主题/语言设置项调整，旧 key 可能已无意义，建议在加载时校验版本号并 clear 或 remove 对应 key
- 读取时发现过期：用时间戳实现软过期（如上文 saveWithExpiry / getWithExpiry），读取即校验，过期则自动删除并返回 null
- 用户手动清理偏好设置：提供“恢复默认”按钮，调用 removeItem 或 clear，而非仅重置 UI 状态
sessionStorage：看似自动，实则需兜底防残留
它绑定标签页生命周期，但以下情况容易“漏清”：
- 页面意外崩溃或强制关闭：用户直接 kill 进程、系统断电等，sessionStorage 不触发销毁。可在 beforeunload 中做轻量清理，例如移除未提交的草稿标记
- 单页应用路由跳转频繁：某些中间态（如向导步骤、筛选条件）若只存 sessionStorage，返回上一页时可能已丢失。若需跨路由保留，应改用 localStorage + 显式清理逻辑
- 新开同域名标签页需隔离上下文：确认业务是否真需要完全隔离（如两个独立表单），避免误把 sessionStorage 当作“轻量登录态”，结果用户新开 tab 就登出
跨标签页同步与清理协同
localStorage 同源共享，修改后其他标签页不会自动更新视图，但可监听 storage 事件响应变化：
- 当一个标签页调用 removeItem 或 clear，其他同源页会收到 storage 事件，可据此同步 UI（如退出登录后所有页自动跳转）
- 清理操作本身不广播“已清空”，所以建议搭配自定义事件或状态管理（如 Redux/Pinia）统一触发清理+通知
- 避免在 storage 事件回调里再调用 setItem，否则可能引发循环触发
用户侧清理路径要透明可预期
开发者无法控制用户何时清缓存，但可降低误操作影响：
- 在设置页注明“清除浏览数据会同时删除本站在本地保存的偏好设置”，避免用户困惑
- 敏感操作（如切换账号）前，先 removeItem 关键 key，而不是等下次登录覆盖——防止旧 token 被意外复用
- 对 localStorage 容量接近上限（如 >4MB）时，可定期遍历 key，按 lastUsed 时间戳淘汰冷数据（需自行记录访问时间）
