[!info] related notes

• 所属 MOC: DevTools Application MOC
• 前置概念: 浏览器客户端存储, Cookie 与 LocalStorage
• 并列排障: Cookie 调试, IndexedDB 与 Cache Storage 调试
• 上位排障: 登录态异常排查路线

DevTools Storage 调试

症状

• 页面一直读到旧配置；
• 切换账号后本地状态串了；
• UI 已重置，但刷新又恢复旧值；
• 同一页面新开 tab 后表现不同；
• 开发环境切换后仍加载上一环境状态。

第一步：确定是哪种 Storage

先区分：

localStorage
→ 同 origin 持久保存

sessionStorage
→ 与具体 tab/page session 绑定

它们都不会像 Cookie 那样自动随 HTTP 请求发送。

第二步：看真实 key/value

在 Application 中记录：

• key；
• value；
• 哪个 origin；
• 刷新前后是否变化；
• 登录/退出/切环境前后是否变化。

不要只凭代码里“应该已经 clear”推断浏览器状态。

第三步：做最小破坏性实验

优先删除单个可疑 key，再刷新页面。

如果问题消失：

本地持久状态参与了根因链。

如果删掉后马上又出现：

应继续找是谁在应用启动时重新写入。

不要一上来 Clear site data，否则会同时清掉 Cookie、IndexedDB、Cache Storage 等证据。

第四步：追写入来源

一旦确定某 key 被错误恢复，继续找：

• 初始化逻辑；
• store persistence plugin；
• route/bootstrap；
• migration/default merge；
• 跨 tab 同步逻辑。

Storage 面板告诉你“现在是什么”，不直接告诉你“谁写的”。

常见根因

• logout 没删用户级 key；
• key 没做 user/tenant namespace；
• schema 升级后旧数据没 migration；
• 默认值 merge 覆盖新状态；
• 环境切换仍使用同 origin/localStorage；
• sessionStorage 与 localStorage 使用预期搞反。

迁移检查

场景：用户 A 退出后用户 B 登录，却继承 A 的筛选条件和 workspace id。

不看正文：

1. 判断先查 Cookie 还是 localStorage；
2. 找到可疑 key 并做单 key 删除实验；
3. 如果刷新后 key 被重新写回，如何继续追写入源；
4. 说明 namespace / cleanup / migration 三种长期修复分别适合什么问题。