Fetch 不处理多源并发协调，需用 Promise.allSettled 实现并发控制、错误隔离与结果组织；应分批限流、按源定制解析逻辑，并对依赖关系采用串行+条件分支处理。
Fetch 本身不处理多源并发请求的协调问题，它只负责单个网络请求的发起与响应。所谓“多源并发”，本质是同时向多个不同域名、路径或服务端接口发起请求，比如拉取用户信息、订单列表、通知未读数三个独立接口。关键不在“多源”，而在“并发控制”“错误隔离”和“结果组织”——这些都需要你用 Promise 机制手动编排。
用 Promise.allSettled 保证全部执行并保留顺序
多源请求往往来自不同服务，稳定性不一。用 Promise.allSettled 最稳妥：它不因某一个源失败而中断其余请求，且结果数组严格按你传入的顺序排列，方便后续映射。
- 每个 fetch 包裹成独立 Promise，例如：
fetch('/api/user').then(r => r.json()) - 所有 Promise 组成数组，传给
Promise.allSettled() - 返回结果形如
[{status: 'fulfilled', value: {...}}, {status: 'rejected', reason: Error}]，可逐项判断处理
限制并发数，避免触发多源限流
即使接口分布在不同域名，浏览器仍有并发连接数限制（通常每域名 6 个），且后端可能对总请求数做全局限流。直接 Promise.all 所有请求容易被拒绝。需主动限流：
- 把请求列表切分成每批 N 个（如 3 或 5），用循环 +
await Promise.allSettled(batch)分批执行 - 或封装一个轻量队列类（如
FetchQueue），内部维护running计数器，空闲时才从队列取下一个请求发起 - 注意：不同源之间不共享连接池，但 TCP 连接、DNS 查询、SSL 握手等资源仍受浏览器整体调度影响
按源分类处理响应，避免混用数据结构
多源返回的数据格式、字段名、错误码体系通常不一致。不要把所有响应统一 .json() 后再塞进一个大数组——应提前约定各源的解析逻辑：
- 为每个 URL 或接口类型绑定专属处理器，例如：
handlers['/api/user'] = res => res.json().then(u => ({id: u.id, name: u.full_name})) - 在
allSettled结果遍历中，根据原始请求索引或 URL 路径调用对应 handler - 失败时也按源记录日志（如 “通知服务超时” vs “订单接口 503”），便于监控定位
需要强顺序或依赖关系？拆解为串行+条件分支
如果某源响应是另一源请求的必要参数（如先查 token，再带 token 请求数据），就不是真正“并发”，而是链式依赖：
- 用
await显式串行：先const token = await fetch(...).then(r => r.text())，再fetch(..., {headers: {Authorization: token}}) - 若部分分支可并行、部分必须等待，可用
Promise.allSettled并行拉取前置数据，再用if判断是否继续后续请求 - 避免在
allSettled回调里嵌套新 fetch —— 容易绕过限流逻辑，也破坏可读性
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
