多账号切换时需严格隔离用户数据：用 userId 前缀区分 localStorage/sessionStorage 键名；IndexedDB 按用户建库或加 userId 字段过滤；敏感数据禁存前端，令牌宜存内存或 HttpOnly Cookie；Service Worker 缓存需按用户动态生成 key 并清理。
多账号切换时，不同用户的数据必须严格隔离，否则会出现信息泄露、状态错乱等问题。HTML5 的 localStorage 和 sessionStorage 是全局的（按源 origin 划分），不随用户登录状态变化而自动区分，因此不能直接存储敏感或用户专属数据。
使用账号标识前缀隔离存储键名
最简单有效的方式是在所有用户相关存储键名前拼接当前用户的唯一标识（如 user_id 或 token hash），避免键名冲突和跨账号读写。
- 登录成功后，获取并缓存当前用户的稳定标识（推荐用服务端签发的不可伪造的 user_id，而非用户名）
- 读写前统一构造带前缀的键：例如
`user_${userId}_cart`、`user_${userId}_theme` - 退出登录时，可选择性清除该用户所有前缀键（遍历 keys 并匹配前缀），或留待下次登录覆盖
利用 IndexedDB 按用户建库或对象仓库
IndexedDB 天然支持多数据库，更适合结构化、大量用户数据的场景。可为每个用户创建独立数据库，或在同一个数据库内按用户划分 objectStore。
- 推荐方案：数据库名包含用户标识，如
`myapp_db_user_12345`；切换账号时关闭旧库、打开新库 - 若复用单库，可在每个 objectStore 中为每条记录显式存储
userId字段，并在查询时加过滤条件 - 注意：IndexedDB 数据不会随 Cookie 或登录态自动清理，需在登出/切换时主动删除对应库或清空 store
敏感数据绝不存于前端存储
密码、token、身份证号、支付信息等，无论是否加前缀，都不应出现在 localStorage/sessionStorage/IndexedDB 中。
立即学习“前端免费学习笔记（深入）”；
- 访问令牌（如 JWT）建议仅短期存于内存（如模块变量或
WeakMap），配合自动刷新机制 - 如需持久化登录态，优先使用 HttpOnly + Secure 的 Cookie，由服务端控制有效性
- 前端只存非敏感的 UI 状态（主题、语言、折叠菜单）或脱敏后的缓存（如商品列表 ID，非完整详情）
配合 Service Worker 实现更精细的缓存策略
当涉及 API 响应缓存时，单纯依赖 Cache API 也会跨账号共享。可通过请求头、URL 参数或自定义缓存键实现隔离。
- 在 fetch 事件中，根据当前用户上下文（如从 indexedDB 读取的 userId）动态生成 cache key
- 例如将
/api/profile缓存为cache_v1_user_12345_profile - 登出时调用
caches.delete()清理对应前缀的缓存，或使用cache.keys()过滤删除
