在一个 Next.js 页面中，如果需要从多个不同的 API 源获取数据，如何合理设计数据获取流程以避免性能瓶颈？

并行是减少等待的机制，但要注意依赖关系

在Next.js的Server Component中，普通的await会阻塞当前执行流。若在同一个函数内依次await两个独立请求，总耗时等于两者之和。正确做法是先调用数据函数，它们会立即发出请求并返回Promise，随后await Promise.all([p1,p2])，此时总耗时约等于最慢请求的耗时。这是因为所有请求在事件循环中同时进行，网络I/O不再串行等待。

但并行并非盲目使用。只有当数据之间没有先后依赖时才可并行。若第二个请求需要第一个请求的响应值，就必须先等待第一个，这种“瀑布流”是必要串行。在Next.js中，同一个渲染周期内对相同URL和选项的fetch请求会被自动去重（memoized），但不同API端点不受影响，所以不会因并行导致重复请求。另外，Promise.all一旦有一个请求失败就会整体拒绝，为隔离故障，常用Promise.allSettled分别处理每个结果。

// 模拟两个独立请求，分别延迟200ms和100ms
const fetchOrders = () => new Promise(resolve => setTimeout(() => resolve(['order1']), 200));
const fetchProfile = () => new Promise(resolve => setTimeout(() => resolve({name: 'Alice'}), 100));

async function loadPageData() {
  // 先发起请求，不等待，它们同时进行
  const ordersPromise = fetchOrders();
  const profilePromise = fetchProfile();
  // 统一等待两个结果
  const [orders, profile] = await Promise.all([ordersPromise, profilePromise]);
  console.log(JSON.stringify({orders, profile}));
}

loadPageData();

{"orders":["order1"],"profile":{"name":"Alice"}}

电商产品页三路API并发获取的平衡设计

一个产品详情页需要展示基础信息、库存状态和用户评价，分别来自不同后端服务。基础信息接口通常稳定且重要，库存可能波动频繁，评价更新较慢。假设三个接口的平均时延分别为120ms、180ms和250ms。若串行获取，首屏至少需550ms；若将基础信息和库存并行，则最快约180ms可得；评价单独发起约250ms完成。具体做法是，在页面顶层的async function Page中先同时调用三个数据函数，其中基础信息和库存使用Promise.all合并等待，并作为关键内容在约180ms内渲染；评价请求单独发起，将其Promise放入<Suspense>包裹的组件，让页面先显示主体，评价区域显示骨架屏，待请求完成后填充。

某次评价接口超时（模拟1.2s），如果不加处理，Promise.all会让整个页面失败。实际决策改为：基础信息和库存使用Promise.all（它们必须同时成功才有意义），而评价使用Promise.allSettled并放置到独立Suspense中。即使评价请求失败，也只会替换其区域为错误提示，不影响主体。这样设计既保证了关键信息快速可见，也隔离了非关键故障。

并行并不是性能银弹：条件与代价

当单个API的响应时间本身极长时，并行只能减少等待协同，不能缩短单请求时延。若页面存在多个可拆分的非关键数据，与其全部等待，不如用Suspense逐块流式发送，让浏览器先展示最高优先级的内容。另外，同时发起大量并行请求可能触发上游API限流，尤其对公共接口。需要评估服务商配额并设计合理的并发上限，例如将请求分组或只预取当前视口需要的数据。

Promise.all的失败语义要求谨慎分组。把业务上不同生命周期和数据重要性混在一组，一次失败可能拖垮整页。更安全的做法是按“必须一起成功”和“可独立降级”分组：前者用Promise.all，后者用Promise.allSettled或单独处理。此外，并行并不消除依赖链——若B需要A的结果，则必须串行，但可把A的请求尽量提前，并缓存其结果，减少重复等待。

容易答错的地方

多个await就是并行

这是常见误解。在单个async函数中，连续写两个await是严格的串行，第二行只有等第一行Promise解决后才开始。要并行必须先将不依赖的请求函数调用（不await）得到Promise，再统一await Promise.all。

Promise.all失败就必须整体降级

Promise.all只要一个拒绝就整体拒绝，所以并不适合所有数据。若某些API可容忍失败，应改为Promise.allSettled并在每个结果中区分status，或拆分成多个小组分别使用不同的错误处理策略，避免总页白屏。

面试官还会怎么问？

把知识连起来