交互事件由浏览器事件触发线程捕获并作为宏任务入队，执行优先级低于微任务；其回调需等待当前宏任务及所有微任务完成后才执行，且dom更新需等到本轮事件循环结束才渲染。
用户交互事件（比如点击、输入、滚动）由浏览器的 事件触发线程 捕获，不是 JS 主线程直接监听硬件信号。它们被统一归为宏任务，进入任务队列后，按事件循环规则调度执行。
交互事件怎么进队列
当用户点击按钮或按下键盘时，操作系统将信号传给浏览器进程，再转发到当前标签页的渲染进程。这里的 事件触发线程 会立即将该事件包装成一个事件对象（如 MouseEvent 或 KeyboardEvent），然后把对应的事件处理函数（比如 onclick 回调）推入 宏任务队列，而不是立刻执行。
- 即使你用
addEventListener绑定多个监听器，每个回调都作为独立任务排队 - 如果页面正执行一个耗时同步任务（如长循环），交互事件不会丢失，只是暂存在队列中等待
- 连续快速点击可能合并为一次事件分发（取决于浏览器优化策略，但回调仍逐个入队）
它在事件循环里排第几
交互事件回调属于宏任务，执行优先级低于微任务，但和 setTimeout、setInterval 处于同一层级。每轮事件循环只执行一个宏任务，之后必须清空全部微任务，才能取下一个宏任务。
- 假设点击发生时，主线程刚执行完同步代码，且微任务队列为空 → 点击回调立即执行
- 若此时微任务队列里有 Promise.then 回调 → 先执行完所有微任务，再执行点击回调
- 若点击瞬间主线程正在跑一个 100ms 的 for 循环 → 点击回调要等到循环结束、微任务清空后才执行
和 DOM 更新的关系
JS 引擎线程与 GUI 渲染线程互斥。交互事件回调里修改 DOM（如 el.innerHTML = 'x'）不会立刻重绘，而是标记为“待更新”。只有当前宏任务 + 所有微任务全部执行完毕，浏览器才会进入渲染阶段：计算样式、布局、绘制。
- 想在点击后立刻看到 DOM 变化？不能靠加长 JS 逻辑，而要用
requestAnimationFrame或强制重排（不推荐） - 频繁交互（如拖拽）建议节流或使用 passive listeners 避免阻塞默认行为判断
-
event.preventDefault()必须在回调同步阶段调用，异步延迟（如 setTimeout 里）已无效
实际开发注意点
交互事件看似“实时”，实则受事件循环节奏约束。卡顿往往不是因为事件没捕获，而是主线程被同步任务或未优化的回调长期占用。
- 避免在 click 或 input 回调里做大量计算或深度遍历 DOM
- 用
debounce处理搜索框输入，用throttle控制滚动监听频率 - 复杂逻辑可拆成微任务（
Promise.resolve().then(...)）让出主线程，提升响应感 - 移动端注意 touchstart/touchend 的 300ms 延迟问题，启用
viewportmeta 或 use passive: true
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
