多租户token刷新需验证串行化刷新与并发复用：同一租户多请求只触发一次refreshapi调用且复用结果，不同租户隔离刷新、互不干扰，并覆盖失败重试、延迟等待及超时清理。
测试多租户鉴权中 Token 刷新的异步队列，核心是模拟并发请求触发 Token 过期、验证队列是否真正“串行化刷新 + 并发复用”，同时确保不同租户的 Token 互不干扰。不能只测单租户，也不能只测刷新逻辑本身。
构造隔离的租户上下文与 Token 状态
每个租户需有独立的 token 存储（如 Map
- 用 Jest 的 jest.useFakeTimers() 控制时间，精准触发过期判断
- 为不同租户生成不同 tenantId（如 'tenant-a' / 'tenant-b'），避免共享缓存导致误判
- 刷新前清空对应租户的 token，或设 expiresAt 为 Date.now() - 1000，强制走刷新流程
并发触发刷新并断言队列行为
启动多个 Promise（代表同一租户的多个并发请求），全部调用 getToken()，观察它们是否：① 只发起一次刷新请求；② 后续请求等待首个 Promise 完成后直接复用结果。示例写法：
tokenrouter-image-generator
下载
通过 Palebluedot AI(PBD)-TokenRouter 的多模态图像生成端点（`/v1/chat/completions`）使用 TokenRouter 兼容的方式生成或编辑图像...
- 用 Promise.all([getToken('tenant-a'), getToken('tenant-a'), getToken('tenant-a')])
- mock refreshApi 调用，内部计数器 ++，断言最终只被调用 1 次
- 检查返回的三个 token 是否完全相同（引用相等 or 字符串相等），确认未重复生成
交叉租户验证隔离性
同时对 tenant-a 和 tenant-b 发起并发请求，验证两者刷新互不影响：
- 分别 mock 各自的 refreshApi，记录调用次数和参数，断言 tenant-a 的刷新不触发 tenant-b 的刷新
- 检查 tenant-a 的 token 不会覆盖 tenant-b 的缓存，反之亦然
- 可故意让 tenant-a 刷新失败（reject），确保 tenant-b 的请求仍能正常完成，不被阻塞
测试边界：刷新中 token 失效、错误重试与超时
真实场景中刷新可能失败或延迟，需覆盖：
- refreshPromise 被 reject 后，下一次 getToken() 应重新尝试刷新（而非沿用失败状态）
- 给 refreshApi 加 setTimeout(..., 200) 模拟网络延迟，验证并发请求确实 await 同一个 Promise
- 设置刷新超时（如 5s），超时后清空 pending promise，下次调用重新开始，避免永久挂起
不复杂但容易忽略租户维度的隔离和 Promise 共享机制。重点不是“能不能刷新”，而是“并发下是否省流量、不冲突、不串租户”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
