先记住这个答案
调用 target.dispatchEvent(event) 时，浏览器会在当前调用栈里按传播规则同步运行监听器，等它们返回后方法才返回。因此监听器同步改了某节点的文本，下一行代码就能读到新文本。监听器内部启动的 Promise、定时器或网络请求不会被 dispatchEvent() 等待；DOM 状态可读也不表示屏幕已经完成绘制。
dispatchEvent()同步调用监听器- 同步 DOM 修改返回后可读取
- 异步回调不会被它等待
- 返回值与取消默认行为有关
同步改文字，下一行就读到
组件通过自定义事件通知外部更新提示，外部监听器直接修改文字。派发函数返回后，调用方可以立刻读取文本内容。
const label = document.querySelector('#status')
const target = document.querySelector('#task')
target.addEventListener('task-done', () => {
label.textContent = '已完成' // 同步修改 DOM
})
target.dispatchEvent(new Event('task-done'))
console.log(label.textContent) // 已完成若监听器改成 Promise.resolve().then(() => ...)，当前同步代码读取时可能仍是旧文字，因为微任务要在当前调用栈结束后执行。
dispatchEvent() 会按捕获、目标和可选冒泡阶段运行监听器；人工派发的事件若未设置 bubbles: true，祖先的普通冒泡监听不会因此自动被调用。
返回值与错误边界
如果派发的是可取消事件，且某监听器有效调用 preventDefault()，dispatchEvent() 返回 false；其他情况通常返回 true。这可以让调用方知道某个操作是否被取消。
监听器抛出的异常会被报告，但不会像普通函数调用那样直接从 dispatchEvent() 抛回调用处供外层 try/catch 接住。不要依赖事件监听器异常来控制派发者的业务分支。
如果组件要让外部“批准或否决删除”，可以创建 new CustomEvent('before-delete', { cancelable: true })，同步派发后检查布尔返回值，再决定是否继续删除。这是同步协议：监听器若先 await 再调用 preventDefault()，派发方已经拿到返回值并继续执行，无法靠它延迟决策。
真正需要等待异步确认，比如弹窗询问用户、服务端校验权限，就应该让调用方拿到 Promise 或明确的回调结果。事件适合通知和同步取消，不会因为监听器声明了 async 就自动变成异步事务。
容易答错的地方
- 把人工派发当成排队异步事件
dispatchEvent()在返回前同步调用监听器，后续同步代码能看到监听器的同步修改。- 把 DOM 可读等同于已绘制
- 布局和绘制可能稍后进行；读取
textContent成功不代表屏幕已经刷新。
面试官还会怎么问？
监听器里 await 后的代码会被等待吗？
不会。监听器发起的异步工作按 Promise 时机继续，派发方法不等待它完成。
返回 false 表示什么？
可取消事件的默认行为被某个监听器有效取消。
浏览器真实点击也是同步触发的吗？
用户事件由浏览器在事件循环中调度；一旦开始派发，监听器按事件处理规则执行。不要把调度时机与 dispatchEvent() 的同步调用混同。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。