测试Promise.all与串行await调用API耗时出现异常结果原因问询

你观察到的耗时差异和串行/并行调用逻辑本身无关，是测试流程没有排除重复请求的缓存和链路复用收益导致的，核心影响因素如下：

• 首先你两段代码调用的是完全相同的8个API接口，先执行的第一段代码不管用串行还是Promise.all，都是首次请求这些接口，没有任何缓存收益，所以耗时更高；后执行的第二段代码调用完全相同的接口时，直接享受到了前面请求留下的各种缓存/复用收益，所以耗时骤降。

具体的影响因素分类 #

• 客户端HTTP缓存：默认情况下，HTTP客户端（浏览器、axios等请求库）都会对GET类型的API请求做缓存，只要接口返回的响应头中缓存规则允许（比如带有Cache-Control: max-age=xxx等标识），相同URL+参数的第二次请求根本不会发往服务端，直接读取本地缓存返回，耗时自然只有几十毫秒。
• 服务端接口缓存：就算你禁用了客户端缓存，API服务端通常也会对热门查询类接口做缓存，比如首次请求会查询数据库生成结果并存入Redis，短时间内相同参数的请求会直接返回Redis中的缓存结果，耗时也会比首次请求低很多。
• 底层网络链路复用：首次请求接口时需要完成DNS解析、TCP三次握手、TLS协商等步骤，这些连接建立后会在短时间内保持（HTTP keep-alive机制），后续的同域名请求可以直接复用已经建立好的TCP连接，省去了建连的耗时开销。

如果要准确对比串行调用和Promise.all并行调用的真实耗时差异，需要排除缓存干扰：

1. 两段代码不要在同一次运行流程中先后执行，分开单独测试，每次测试前清空客户端缓存、禁用HTTP缓存
2. 可以给每个API请求增加一个随机查询参数（比如?v=${Date.now()}），保证每次请求的URL唯一，避免命中任何缓存
3. 多次测试取平均值，排除网络波动的影响

排除干扰后你会得到符合预期的结果：串行调用的总耗时是8个接口的耗时之和，Promise.all并行调用的总耗时等于8个接口中最慢的那个的耗时，并行耗时会远低于串行。

内容的提问来源于stack exchange，提问作者nonamenoname