关键是在请求拦截器处理401响应、token刷新函数及路由守卫中设断点，验证租户标识传递、刷新请求构造、新token按租户维度正确存储。
在 JavaScript 中调试多租户场景下的 Token 过期刷新逻辑，关键不是“在 Token 过期时打断点”（因为过期是服务端判断、客户端通常无法精确感知“过期瞬间”），而是在 Token 刷新请求发出前、刷新失败后、或拦截器中处理 401/403 响应的位置设置断点，从而观察鉴权流程是否按预期触发刷新、是否正确携带租户标识（如 tenant-id 请求头）、是否更新了本地 Token 状态。
在请求拦截器中对 401 响应打断点（最常用）
多数项目使用 Axios 或自定义 fetch 封装。Token 过期通常由后端返回 401（未授权）触发刷新逻辑。你应在拦截响应的错误分支里设断点：
- 找到类似
axios.interceptors.response.use(..., error => { ... })的代码 - 在判断
error.response?.status === 401的 if 块内部第一行加断点 - 确认此处是否读取了当前租户上下文（例如从 Vuex/Pinia store、URL path、或全局变量中获取
tenantId） - 检查刷新请求（如
refreshToken(tenantId)）是否被调用，且参数正确
在 Token 刷新函数内部打断点
刷新函数（如 refreshAccessToken()）是核心逻辑所在。务必在此处设断点并验证：
Auth0 Token Vault
下载
通过 Auth0 Token Vault，代表已认证用户访问 Gmail、Slack、Google Calendar、GitHub 等第三方服务以及自定义 Auth0 连接。使用...
- 是否传入了正确的租户标识（例如作为 URL path 参数：
/api/v1/tenants/{tid}/auth/refresh，或作为 header：tenant-id: abc123） - 是否使用了旧 Token（或 refresh token）+ 租户信息构造请求
- 是否在成功后将新 Token 正确写入 localStorage / cookie / store，并带上租户维度（避免跨租户污染）
在路由守卫或 API 调用前检查 Token 有效性时打断点
有些方案会在发起请求前主动校验 Token 是否即将过期（如剩余
- 查找类似
isTokenExpired(token)或shouldRefreshToken()的函数 - 确认它是否结合了当前租户的 Token（而非全局唯一 Token）进行校验
- 若使用 JWT，注意解析 payload 时是否取到了正确的
exp字段，且时间比较基于客户端时间（需考虑时钟偏移）
利用浏览器 DevTools 的 Network 断点辅助定位
如果刷新请求本身没发出去，或发错了租户地址，可用 Network 断点快速捕获：
- 打开 Chrome DevTools → Network → 右键任意请求 → “Break on” → “XHR/Fetch”
- 复现 Token 过期场景（如手动修改 localStorage 中的 token exp 时间为过去值）
- 触发一个受保护接口，执行会停在 fetch/XHR 调用栈，可逐层查看调用来源和参数
- 特别关注请求 URL、Headers（尤其是
tenant-id、Authorization）、以及调用栈中是否包含租户上下文提取逻辑
不复杂但容易忽略：多租户下 Token 存储和刷新必须隔离。打断点时务必确认你看到的是「当前租户」的 Token 和刷新行为，而不是默认租户或缓存残留值。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
