调试时单步跳过await语句的具体行为是什么？

同步代码的调试基准 #

先明确同步代码中单步跳过的预期行为：

function myFunction(a)      // line 1
{                           // line 2
    someFunction(a);        // line 3
    someOtherFunction(a);   // line 4
}                           // line 5

当调试器暂停在第3行时，按下单步跳过按钮，会完整执行someFunction，返回后直接暂停在第4行。这种行为和在第4行设断点运行类似，但递归等场景下存在差异。

异步await语句的调试疑问 #

对于含await的异步代码：

async function myAsyncFunction(a)  // line 1
{                                  // line 2
    await someAsyncFunction(a);    // line 3
    someOtherFunction(a);          // line 4
}                                  // line 5

当调试器暂停在第3行的await语句时，单步跳过的行为存在模糊性：是等效于在第4行设断点？还是强制同步执行异步操作？

比如someAsyncFunction的实现为：

function someAsyncFunction(a)
{
    return new Promise(resolve => setTimeout(resolve, 60000));
}

若按设断点逻辑，网站会在一分钟内保持可交互，之后才被调试器暂停；若强制同步执行，浏览器会陷入一分钟无响应——这两种都不符合预期。

主流引擎及Node.js的实际表现 #

Chrome/Blink #

单步跳过await语句后，调试器会执行到Promise创建并返回的逻辑，随后立即暂停在第4行。此时浏览器保持可交互状态，Promise完成后代码会继续执行，但调试器不会自动暂停，除非第4行有预设断点。

Firefox/Gecko #

行为与Chrome一致：单步跳过await后直接暂停在第4行，浏览器正常响应。Promise resolved后代码自动执行，无额外断点则不触发暂停。

Safari/WebKit #

遵循相同逻辑：单步跳过await后暂停在后续代码行，不阻塞执行环境，Promise完成后代码继续执行，无断点则不暂停。

Node.js #

表现和Chrome完全一致：单步跳过await后调试器暂停在await的下一行，事件循环正常运行，Promise完成后代码自动推进，无断点则不会再次触发暂停。

行业共识 #

目前主流调试器的统一行为逻辑是：单步跳过await语句时，不会等待Promise完成，而是直接推进到await之后的下一行代码暂停。这既避免了阻塞执行环境（防止浏览器/Node无响应），也符合开发者对“单步跳过当前语句”的直觉——跳过await的语法处理步骤，直接定位到下一行代码，而非等待异步操作结束。

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