async/await通过将await后代码作为微任务执行，使其在宏任务结束后立即运行、优先于settimeout等宏任务，但若微任务内含大量计算或dom操作仍会阻塞渲染；浏览器仅在宏任务完成且微任务清空后检查并触发渲染。
async/await 本身不直接参与渲染，但它通过控制 JS 主线程的执行节奏，间接决定渲染何时发生、是否及时、是否被阻塞。关键在于它如何与事件循环、宏任务/微任务队列以及渲染时机配合。
async/await 是微任务驱动的“暂停点”
每个 await 表达式背后都隐含一个 Promise 状态切换。当 await 遇到 pending 的 Promise 时，函数会暂停执行，并把后续代码包装成一个微任务（microtask），等 Promise settle 后再排队执行。
- 这个微任务会被插入当前宏任务（比如点击事件、脚本执行）结束后的微任务队列尾部
- 它比 setTimeout 回调（宏任务）优先级高，一定在下一次渲染前执行完
- 因此，连续的 await 不会打断渲染流程，但也不会主动触发渲染——渲染只发生在宏任务之间
await 不等于“让出渲染权”，但能避免长同步阻塞
很多人误以为 await 会立刻交还控制权给渲染线程。实际上，await 只是把后续逻辑推迟到微任务阶段；如果微任务里仍有大量计算，依然会延迟渲染。
- 例如：
await fetch(...); console.log('done'); for (let i = 0; i —— 渲染仍要等到这个 for 循环跑完 - 真正让出渲染权的是“宏任务边界”：比如用
setTimeout(() => {}, 0)或queueMicrotask(() => {})拆分任务 - await 的价值在于结构清晰地组织异步依赖，而非自动优化渲染
浏览器何时渲染？await 如何“搭上顺风车”
浏览器默认在每个宏任务执行完毕、且微任务队列清空后，检查 DOM/CSS 是否有变更，再决定是否触发重排重绘。await 写法天然适配这一节奏：
- 发起请求（如
await fetch()）→ 网络线程处理 → 响应返回后将 resolve 回调推入微任务队列 - JS 引擎执行完当前宏任务 → 立即执行该微任务（含 await 后续代码）→ 修改 DOM → 触发样式/布局计算
- 紧接着，浏览器进入“渲染检查点”：若检测到变更，就走完整渲染流程（构建渲染树 → layout → paint）
实际开发中要注意的协同细节
写 async/await 时，若希望用户尽快看到反馈（比如加载状态、骨架屏），不能只靠 await 等接口，还要主动管理渲染时机：
- 在 await 前先更新 UI：
loading.value = true; await fetch(...); loading.value = false; - 避免在 await 后集中大批量 DOM 操作；可考虑
requestIdleCallback或分片更新 - 注意 Vue/React 等框架的响应式更新也是异步的，
await nextTick()才能确保 DOM 已更新 - 不要用 await 包裹纯计算型操作（如大数组排序），这类同步耗时仍会卡住渲染
