多账号切换时需主动隔离前端存储：用 userid 前缀管理 localstorage 键名，indexeddb 按用户建库或加 userid 字段过滤，敏感数据严禁存储，api 缓存按用户动态命名并清理。
多账号切换时，HTML5 本地存储默认不隔离——localStorage 和 sessionStorage 都按协议+域名（origin）划分作用域，与用户身份无关。直接存 `cart` 或 `theme` 这类通用键，会导致 A 账号登出后，B 账号打开页面仍读到 A 的购物车。真正有效的隔离，靠的是“主动加前缀”和“严格清理”，不是依赖浏览器自动行为。
用 userId 前缀统一管理所有键名
这是最轻量、兼容性最好、也最易落地的方案。核心是：登录成功后，拿到服务端签发的稳定 userId（别用用户名或邮箱，防篡改），所有用户专属数据的键都拼上前缀。
- 写入时构造带前缀的键：比如
user_12345_cart、user_12345_last_search - 读取时同样拼接前缀再
getItem()，避免跨账号误读 - 退出登录时，遍历
Object.keys(localStorage)，用key.startsWith('user_' + oldId)批量清除，不残留旧态 - 注意：不要手动拼接字符串做 key，封装成工具函数，例如
getStorageKey('cart')，便于后续统一调整格式
IndexedDB 按用户建库或加字段过滤
当缓存数据结构复杂、体积较大（如离线商品列表、聊天记录），IndexedDB 比 localStorage 更合适。它支持事务和索引，天然适合多用户场景。
- 推荐做法：数据库名包含 userId，如
myapp_db_user_12345；切换账号时关闭旧库、打开新库，彻底物理隔离 - 若复用单库，必须在每条记录中显式存
userId字段，并在所有查询中加上IDBKeyRange.only(userId)或游标过滤 - 登出时调用
indexedDB.deleteDatabase(dbName)，或清空对应 objectStore，不能只删数据不删库
敏感数据绝不进前端存储
无论是否加前缀，以下内容禁止出现在 localStorage、sessionStorage、IndexedDB 中：
- 密码明文或加密后结果
- JWT 访问令牌（token）——应短期存在内存变量或 WeakMap，配合自动刷新
- 身份证号、银行卡号、完整手机号
- 未脱敏的用户隐私字段（如真实姓名、住址）
前端只存非敏感状态：主题色、语言、菜单展开状态、已浏览商品 ID 列表等。登录态凭证交由 HttpOnly + Secure Cookie 管理，由服务端控制有效性。
配合 Service Worker 实现 API 缓存隔离
如果用了 Cache API 缓存接口响应（如 /api/user/profile），默认也会跨账号共享。需在 fetch 事件中动态生成 cache key：
- 从 IndexedDB 或内存中读取当前 userId，拼入 cache 名称，如
api_cache_v1_user_12345 - 请求时检查 URL 是否含用户上下文，或通过自定义 header 标识身份，再决定用哪个 cache
- 登出时调用
caches.delete('api_cache_v1_user_12345')，避免下次登录误用旧缓存
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
