javascript 不直接管理 session，其核心是前端显式传递租户标识（如 x-tenant-id）并按租户隔离状态、缓存与会话，避免跨租户数据混淆和越权访问。
JavaScript 本身不直接管理 Session，Session 是服务端概念。所谓“JS 中的 Session”，实际是指前端如何配合后端，在多租户系统中正确传递和隔离租户上下文，避免状态混淆。关键不在 JS 做隔离，而在于 JS 准确携带租户标识（如 tenantId），让后端能按租户划分数据存储与访问权限。
租户标识必须全程显式传递
不能依赖全局变量或 localStorage 混存多个租户数据。每次请求都应明确附带租户身份：
- API 请求头中添加 X-Tenant-ID（推荐，安全且不易误用）
- URL 路径前缀如
/t/{tenantId}/api/users（适合路由级隔离） - 请求体或查询参数中传 tenantId（仅限低敏感场景，需后端严格校验）
前端状态管理需按租户分域
使用状态库（如 Redux、Pinia、Zustand）时，不要把所有租户数据塞进同一 store。建议：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 为每个活跃租户创建独立 store 实例（例如：storeMap.get(tenantId)）
- 在切换租户时清空当前租户缓存（localStorage/sessionStorage 键名加 tenantId 前缀，如
cache_${tenantId}_userList） - 避免跨租户复用 token 或 auth state——登录后必须绑定 tenantId，刷新 token 也需携带该标识
避免共享会话导致的越权风险
浏览器同域下 Cookie 默认共享，若多个租户共用同一域名（如 saas.example.com），必须：
- 后端设置 Cookie 的 Path 为
/t/{tenantId}，或使用 SameSite=Lax/Strict + 显式 tenant 绑定 - 前端登出时调用
fetch('/auth/logout', { headers: { 'X-Tenant-ID': currentTenant } })，确保只销毁当前租户会话 - 禁止通过 localStorage 存储敏感租户凭证（如未加密的 access_token），改用 httpOnly Cookie + 前端仅存 tenantId
开发阶段要模拟租户切换场景
本地调试时容易忽略租户隔离，建议：
- 在 DevTools Console 手动切换
window.__CURRENT_TENANT__ = 'tenant-a'，验证请求是否自动带上对应 header - 用 Cypress 或 Playwright 编写跨租户测试用例，比如“用户 A 在 tenant-1 创建数据，切换到 tenant-2 后无法读取”
- 在 Axios 拦截器里加断言：
if (!config.headers['X-Tenant-ID']) throw new Error('Missing tenant context')
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
