浏览器事件是宏任务，触发后回调入宏队列并待当前宏任务结束后执行；其内部产生的微任务在该回调结束后立即全部执行，不等下次宏任务，也不被渲染打断。
浏览器事件（如点击、输入、DOMContentLoaded）本身是宏任务，触发后回调立即入队；但回调内部若产生 Promise 或 queueMicrotask，这些微任务会在该事件回调执行完后**立刻执行**，不等下一轮宏任务，也不被渲染打断。
事件触发属于宏任务，有明确的入队时机
用户交互（click、input）、资源加载完成（load）、DOM 解析完成（DOMContentLoaded）等，均由浏览器在合适时机将对应回调推入**宏任务队列**。它们不是同步执行的——即使你绑定了 btn.addEventListener('click', handler)，handler 也总是在当前正在运行的宏任务（比如上一个定时器、脚本块或渲染后的空闲）结束后才被取出执行。
- 例如：页面加载时，
<script>是第一个宏任务；执行完后，浏览器检查是否有 DOMContentLoaded 可触发，若有，则将其回调作为下一个宏任务入队。 - 再如：用户快速连点两次按钮，两个 click 回调会按触发顺序依次进入宏任务队列，不会合并或丢弃。
事件回调里产生的微任务，紧接其后全部执行
一旦某个事件回调开始执行（比如 click 处理函数），它就是当前宏任务的主体。当这个函数执行完毕（包括所有同步语句和可能的嵌套调用），JS 引擎立刻检查微任务队列，并一次性清空——无论期间产生了多少层 Promise.then、queueMicrotask 或 MutationObserver 回调。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 这意味着：你在 click 回调里写
Promise.resolve().then(() => console.log('A'))，输出 A 一定发生在该 click 回调结束之后、下个宏任务（比如 setTimeout）开始之前。 - 哪怕这个 click 回调里又触发了另一个事件（如
el.click()），那个新事件的回调仍是宏任务，要排到本轮微任务清空之后才执行。
DOM 更新与渲染会等微任务全部跑完
浏览器不会在事件回调刚结束就立刻重绘。它遵循“宏任务 + 全部微任务 → 渲染”节奏。所以如果你在 click 中修改了 DOM（如 el.innerText = 'done'），又紧接着用 Promise.then 去读取 el.offsetHeight，拿到的是更新后的值——因为 DOM 已变更，且微任务执行时页面尚未渲染，但布局计算已就绪。
立即学习“Java免费学习笔记（深入）”；
- 注意：
requestAnimationFrame是特例，它属于宏任务，但浏览器会尽量把它安排在下一帧渲染前执行，优先级高于普通 setTimeout，但低于微任务。 - 真正阻断微任务执行的，只有同步代码卡死（如 while(true)）或抛出未捕获异常导致当前宏任务提前终止。
调试时可借助 DevTools 的“Tasks”和“Microtasks”标签
Chrome DevTools 的 Performance 面板录制后，展开 Main 线程，能看到清晰标记的 Task（宏任务）、Microtask 和 Rendering 块。把鼠标悬停在 Task 上，能看见它对应的事件类型（如 click、setTimeout）；点开 Microtask 区域，可看到每个 Promise.then 的调用栈来源。
- 技巧：在事件回调开头加
console.log('click start')，结尾加console.log('click end')，再加一个Promise.resolve().then(() => console.log('microtask'))，就能直观验证三者顺序。 - 避免误区：不要认为 “事件触发 = 立即执行回调”，也不要以为 “Promise.then 总比 setTimeout 快” 就等于 “它在事件触发前发生”——它的快，是相对于下一个宏任务而言的。
