前端 localstorage 需通过租户前缀（如 tenant_abc123_）实现隔离，防止跨租户数据污染；须封装工具类自动拼接前缀、校验键名、清理旧租户数据，并与后端 tenant_id 严格对齐。
多租户 SaaS 系统中，前端 localStorage 本身不支持天然的租户隔离——它按域名作用域共享，同一域名下所有租户（无论登录谁）读写的都是同一份存储。若不做处理，A 租户存的数据可能被 B 租户意外读取或覆盖，尤其在单页应用（SPA）频繁切换租户或管理员模拟登录时风险突出。因此，“利用前缀隔离 localStorage”是一种轻量、可控、无需后端改造的客户端数据隔离实践，核心是**人为约定并强制执行键名空间划分**。
前缀隔离的本质与适用场景
前缀隔离不是一种独立架构层级，而是应用层对 localStorage 的使用规范：所有写入 localStorage 的 key 都必须以当前租户标识（如 tenant_abc123_）开头，例如：
✅ tenant_abc123_user_preferences
✅ tenant_abc123_last_route
❌ user_preferences（无前缀，跨租户污染风险）
❌ abc123_user_preferences（无统一前缀，无法批量清理或审计）
它适用于以下情况：
• 前端需缓存租户专属配置、UI 状态、临时表单草稿等非敏感但需隔离的数据
• 后端已通过 JWT 或请求头传递租户 ID（如 X-Tenant-ID: abc123），前端可稳定获取
• 不依赖服务端 session 绑定，适合纯静态部署或边缘渲染场景
关键实现环节
要让前缀隔离真正生效，不能只靠开发自觉，必须嵌入到数据访问链路中：
-
租户上下文初始化：在用户完成身份认证（如登录成功或管理员切换租户）后，立即从响应头、JWT payload 或路由参数中提取
tenantId，并持久化到全局状态（如 Pinia/Vuex store 或 React Context），作为后续所有 localStorage 操作的唯一租户信源 -
封装安全的 Storage 工具类：提供
set(key, value)、get(key)、remove(key)等方法，内部自动拼接前缀：const fullKey = `tenant_${tenantId}_${key}`;
避免业务代码直接调用原生localStorage.setItem() - 强制前缀校验与拒绝写入：工具类在写入前检查 key 是否已含合法前缀；若未命中，抛出警告或静默丢弃（防止误用裸 key）
-
租户切换时的自动清理：切换租户前，调用
clearTenantData()方法，遍历所有 key，仅删除以旧租户前缀开头的条目（可用Object.keys(localStorage).filter(k => k.startsWith('tenant_oldid_'))）
典型风险与规避方式
前缀隔离看似简单，但容易在边界场景失效：
- 管理员模拟租户（impersonate）：此时页面仍运行在原管理员会话下，但需呈现目标租户视角。必须确保模拟开始时立即更新全局 tenantId，并触发 localStorage 前缀切换与旧数据清理，否则缓存仍属管理员租户
-
多标签页共存不同租户：浏览器 localStorage 是域名级共享，若用户在两个标签页分别登录租户 A 和 B，它们会互相覆盖对方的前缀数据。解决方案是限制单域名仅允许一个活跃租户（如检测到冲突则提示“已在其他窗口登录，请刷新”），或改用
sessionStorage存储强会话态数据 - 敏感数据不应存于 localStorage：即使加了前缀，localStorage 仍易受 XSS 攻击窃取。token、密码、PII 等必须走 httpOnly cookie 或内存变量，前缀隔离只用于低敏感度状态数据
与后端隔离策略的协同
前端前缀隔离是纵深防御的一环，必须与后端数据隔离对齐：
- 前端使用的
tenantId必须与后端TenantContext中的 ID 完全一致（大小写、编码、是否带命名空间），否则会出现“前端存 A，后端查 B”的逻辑错位 - 若后端采用共享数据库+tenant_id 字段模式，前端前缀应与该字段值严格对应；若后端用独立数据库，前缀可简化为租户短码（如数据库名缩写），但需建立映射关系并统一维护
- 建议在登录接口返回中显式携带标准化
tenant_id字段，避免前端从 JWT 或 URL 中自行解析，减少歧义
