Service Worker 中 Promise 状态不可变，须用新 Promise 替换旧引用以实现状态更新；正确做法是用变量（如 currentTokenPromise）动态赋值新 Promise，配合错误处理与生命周期钩子的 waitUntil/return 机制确保异步可靠性。
Service Worker 的异步生命周期中，Promise 状态管理的关键不在于“改变 Promise 本身”，而在于**用新 Promise 替换旧引用**。因为 Promise 状态一旦 fulfilled 或 rejected 就不可变，所以不能“刷新”一个已解析的 Promise，只能让所有依赖方 await 一个新的、代表最新状态的 Promise。
为什么不能复用或修改已有 Promise
Service Worker 中常需管理令牌刷新、资源预加载、缓存更新等长期有效的异步任务。若把获取令牌的逻辑封装成一个 Promise 并全局复用：
- 一旦该 Promise 被 resolve（比如返回了过期的 token），它永远返回那个旧值；
- 后续调用 await tokenPromise 不会重新执行逻辑，只是立即拿到缓存结果；
- 试图在 resolve 后再调用 reject 或再次 resolve —— 完全无效，状态不可逆。
正确做法：用变量持有 Promise 引用，并动态更新
核心是维护一个可变的变量（如 currentTokenPromise），每次需要刷新时，创建并赋值一个全新的 Promise：
- 初始时：let currentTokenPromise = fetchNewToken()；
- 定时刷新时：currentTokenPromise = fetchNewToken()（覆盖旧引用）；
- 拦截请求时：const token = await currentTokenPromise —— 自动等待当前正在运行的那个 Promise 完成。
这样，所有并发请求都 await 同一个变量，但该变量指向的 Promise 实例可能已更新，自然实现“请求等待最新令牌”。
配合错误处理与降级策略
仅替换 Promise 引用还不够，还需保障失败时的可用性：
- fetchNewToken() 内部应捕获网络/认证错误，避免 Promise 永远 pending 或直接 rejected；
- 可设计 fallback 逻辑：比如首次失败后，返回上一个有效 token（需额外缓存）或抛出明确错误供 fetch 事件处理；
- 在 install/activate 阶段避免阻塞，用 self.skipWaiting() 和 clients.claim() 配合 Promise.resolve() 主动推进流程。
生命周期钩子中的 Promise 使用要点
Service Worker 各事件回调（install、activate、fetch）本身不返回 Promise，但内部常需异步操作：
- install：必须 waitUntil(new Promise(...))，否则安装失败；
- activate：同样用 waitUntil() 确保清理缓存等操作完成后再激活；
- fetch：需 return 一个 Promise（如 cache.match() 或 fetch()），浏览器会等待其 resolve 后返回响应。
这些 Promise 必须真实反映异步操作状态 —— 不能 resolve 空值、不能漏掉 catch 导致 unhandled rejection，否则可能中断生命周期。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
