TypeScript中如何验证函数调用是否真正处于并行执行状态

AI 小北

2026-11-1

定位异常根源的调试工具

Chrome DevTools 性能面板
录制loadImages执行的全流程，可快速定位问题层级：
- 如果所有loadImage的调用触发时间集中在同一毫秒级区间，说明代码层面已完成并行调用，级联效果来自浏览器网络层或服务端限制
- 如果loadImage的调用触发是依次错开的，说明代码逻辑存在阻塞（比如同步执行逻辑、未yield的微任务、内部封装的串行加载队列），导致没有真正并行发起调用
  面板中可直接查看每个任务的调度时间，以及请求发起前的具体等待原因
Chrome DevTools Network 面板的请求时间细分
点击单个图片请求，查看Timing标签页里的Stalled字段：如果该字段占了请求等待时长的绝大部分，说明请求没有被阻塞在代码执行阶段，级联是浏览器连接池限制、资源优先级排队、缓存锁等网络层规则导致的
轻量日志埋点
在loadImage函数的最开头添加时间戳日志，打印当前触发时间和对应url：
```
private async loadImage(url: string): Promise<Image> {
  console.log('loadImage triggered:', performance.now(), url);
  // 原有加载逻辑
}
```
直接观察控制台输出的时间差，如果所有日志的输出时间差在几毫秒内，即可确认代码已经并行触发了调用
Performance Observer API
注册网络请求类型的观测器，记录每个请求的真实发起时间，不受DevTools的展示逻辑干扰，适合精准排查时序偏差问题

并行执行状态的简单校验方法

代码层校验
现有代码存在隐蔽逻辑问题：urls.map的async回调中，既没有await this.loadImage(url)也没有返回该Promise，导致Promise.all根本不会等待loadImage的执行完成，触发完所有调用就直接结束等待，这个写法本身就会导致请求时序观测偏差。
修正后添加触发点日志：
```
private async loadImages(urls: string[]): Promise<void> {
  console.log('loadImages start:', performance.now());
  await Promise.all(urls.map(async (url) => {
    console.log('call loadImage:', performance.now(), url);
    // 必须加await或return，否则Promise.all无法跟踪loadImage的执行状态
    await this.loadImage(url);
  }));
}
```
所有「call loadImage」的日志输出时间差如果在1ms以内，即可确认代码层面是并行触发的，不存在串行调用逻辑
网络层校验
临时将请求地址换成跨域静态资源，绕开同域连接池限制：如果跨域请求可以正常并行发起，说明之前的级联是同域并发数限制导致的（Chrome在HTTP/1.1协议下，对单个域名最多支持6个并发连接，超出的请求会进入连接队列依次等待，视觉上就是请求瀑布的级联效果）
另外可以临时给请求添加随机查询参数绕开强缓存，排除缓存锁导致的请求排队问题

常见的级联触发原因

HTTP/1.1 同域并发连接上限，超出连接池的请求会被强制排队
浏览器对低优先级资源（比如非可视区图片）的调度延迟，导致请求依次发起
服务端对客户端IP的并发请求限流，强制让请求依次处理
loadImage内部实现存在全局串行队列，没有真正并行触发图片加载

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