异步事件处理器与阻止默认行为：为何调用顺序影响结果？

核心逻辑：事件默认行为不等异步代码 #

浏览器处理表单submit事件的规则是：在事件监听器的同步代码执行完毕后，立刻检查是否调用过preventDefault()，没调用就直接执行默认提交行为。

而async函数里的await会打断同步执行流程：

1. 碰到await asyncFetching()时，浏览器会先启动这个异步请求，然后暂停当前监听器函数，把剩下的代码（包括event.preventDefault()）丢进微任务队列排队。
2. 主线程不会等异步请求完成，直接继续走事件流程——这时候因为还没调用preventDefault()，浏览器立刻触发表单默认提交（跳转页面或刷新）。
3. 等异步请求完成后，微任务队列里的代码才会执行，但这时候默认行为已经结束了，preventDefault()自然没用。

两段代码的差异 #

有效代码 #

form.addEventListener('submit', async(event) => {
  // 同步代码
  event.preventDefault(); // 同步执行，立刻告诉浏览器要阻止默认行为
  await asyncFetching(); // 这里暂停，但阻止指令已经生效
  // 后续异步代码
});

这段里preventDefault()是在await前同步执行的，浏览器在同步阶段就收到了阻止信号，所以不会触发默认提交。

无效代码 #

form.addEventListener('submit', async(event) => {
  // 同步代码
  await asyncFetching(); // 暂停函数，主线程直接执行默认提交
  event.preventDefault(); // 晚了！默认行为已经跑完了
  // 后续异步代码
});

这里await先暂停了监听器，浏览器没等到preventDefault()就直接执行了默认提交，等异步请求结束再调用阻止已经没用。

你忽略的关键点 #

你以为“事件处理器执行完毕→事件完成”，但async函数的执行是分阶段的：

• 碰到await后，函数会暂停，把后续逻辑推迟到微任务阶段，而事件的默认行为是在当前宏任务（事件触发的同步流程）结束时就执行，完全不会等微任务里的代码。
• 总结：默认行为只等监听器的同步代码，不等异步操作。

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