Promise.any() 不适合镜像请求，因其无法中止其余请求、不暴露拒绝原因；应使用 fetch + AbortController 配合超时与主动取消，并辅以镜像排序、频次限制和健康探针。
Promise.any() 在镜像请求中到底适不适合用？
不适合直接用，除非你明确接受「只要一个成功就忽略其余响应」的语义。它不等价于“并发发请求、取最快那个”，而是“取第一个 fulfilled 的结果，但其他 Promise 仍在后台运行且无法取消”。镜像请求的真实需求通常是：发多个请求 → 拿到首个有效响应 → 主动中止其余请求（避免资源浪费和后端压力）。Promise.any() 不提供中止能力，也不暴露其余 rejection 原因，容易掩盖超时、网络错误等关键信息。
为什么 fetch + AbortController 是更可控的选择？
镜像请求的核心控制点是「超时中断」和「主动取消」，而 fetch 配合 AbortController 能精准做到。每个请求可绑定独立 signal，一旦某个请求 resolve，立刻调用其他 signal 的 abort() 方法。这比依赖 Promise.any() 的被动等待更可靠，也避免了无效请求持续占用连接或触发后端日志。
- 所有镜像 URL 应并行发起，但每个都带自己的
AbortSignal - 用
Promise.race()包裹一组带 signal 的fetch调用，捕获首个成功响应 - 成功后遍历剩余 controller，逐个调用
abort()（注意：已 resolve 或 reject 的 signal 调用 abort 无副作用） - 务必设置合理的
timeout（如 3s），否则慢节点会拖垮整体响应时间
如何避免并发请求把镜像服务器打挂？
高并发下盲目并发所有镜像地址，可能触发对方限流甚至封禁 IP。真实部署必须加约束：
- 镜像列表按历史成功率/RT 排序，优先请求前 2–3 个，其余作为 fallback 延迟启动（比如首请求 800ms 未返回再发第 4 个）
- 对同一镜像域名做请求频次限制，例如 1 分钟内最多允许 5 次请求，超出则跳过该镜像
- 服务端需在响应头中返回
X-Mirror-Source: cdn-a，前端记录各镜像实际耗时与成功率，用于动态调整优先级 - 不要复用同一个
AbortController实例——每个fetch必须有独立 signal，否则一次 abort 会误杀全部
常见错误：把 Promise.any() 和超时混搭导致逻辑断裂
有人会写 Promise.any([fetchA(), timeout(2000)])，这是危险的。因为 timeout(2000) 是一个立即 reject 的 Promise，一旦触发，Promise.any() 就会以该 rejection 结束，而此时 fetchA() 仍在运行，既没被 cancel，也没人监听它的后续结果，造成“幽灵请求”。
正确做法是让 timeout 控制 signal：
const controller = new AbortController();<br>setTimeout(() => controller.abort(), 2000);<br>fetch(url, { signal: controller.signal })这样 fetch 真正被中断，底层连接也会关闭。
真正难处理的是 DNS 缓存、TCP 握手失败、TLS 协商卡住这类底层问题——它们可能让 fetch 卡在 pending 状态，连 abort 都来不及响应。生产环境必须配合服务端健康探针 + 客户端请求计数熔断，不能只靠 Promise API 层面的机制兜底。
