宏任务阻塞主线程导致输入响应延迟，因输入事件回调需等待当前宏任务及微任务全部执行完毕才入队；应避免长宏任务、用分片/web worker处理重操作、合理使用微任务与requestanimationframe优化调度。
宏任务执行时机本身不“干扰”用户输入，真正造成卡顿或响应延迟的，是长宏任务独占主线程，导致后续输入事件回调无法及时入队或执行。
宏任务执行完才处理新输入
用户点击、键盘输入等事件触发后，其回调函数需等待当前宏任务（含同步代码和全部微任务）彻底执行完毕，才会被推入宏任务队列。如果前一个宏任务耗时过长（比如 80ms），那这次点击就只能排队等待——不是浏览器没收到，而是还没轮到它执行。
- 输入事件回调不会插队，也不比 setTimeout 优先；它们按触发时间顺序进队
- 高频输入（如连续 typing 或 scroll）若未节流，可能瞬间堆积十几个宏任务，进一步加剧排队延迟
- 可借助 PerformanceObserver 监听
longtask，确认是否因某段 JS 阻塞了输入响应
避免在宏任务中做重操作
很多卡顿源于把本该分片或移交后台的任务，一股脑塞进单个宏任务里：比如点击后同步渲染 5000 行表格、遍历全量 DOM 节点计算样式、或在 input 回调里反复触发 layout。
- 批量 DOM 更新改用 DocumentFragment 或 innerHTML 一次性写入，减少重排重绘次数
- 大数组处理别用 for 循环硬算，改用 requestIdleCallback 分片，或交给 Web Worker（纯计算场景）
- 对实时性要求不高的更新（如统计上报、日志埋点），用 setTimeout(fn, 0) 推迟到下一周期，避开交互高峰
用微任务协调状态，但别滥用
微任务（Promise.then、queueMicrotask）能在宏任务结束后立刻执行，适合做轻量同步、状态归一化，但它不触发渲染，也不能替代响应式更新。
- 例如：点击按钮后先用 queueMicrotask 更新 store 状态，再让 UI 框架基于新状态自动 re-render
- 但不要在微任务里嵌套大量 Promise.then，否则会把渲染无限推迟——微任务队列清不完，浏览器就不进入渲染阶段
- 需要视觉反馈的操作（如按钮 loading 态），应在宏任务开始时同步设置，而不是等微任务里再改
主动让出控制权，保障输入优先级
浏览器不会主动给用户输入“加急通道”，但你可以通过调度策略，让关键交互更快获得执行机会。
- 对 click/touch 事件处理器，开头就禁用按钮、设 loading，并 clearInterval / clearTimeout 相关定时器，防止竞态
- 滚动或输入类高频事件，启用 { passive: true } 并配合 debounce 或 throttle，减少宏任务注册数量
- 使用 requestAnimationFrame 处理动画关联逻辑，它天然对齐渲染帧，且比 setTimeout(0) 更准时
