宏任务队列不会被清空，而是按FIFO顺序逐个取出执行；每次仅执行一个宏任务，待其同步代码、微任务队列和渲染全部完成后，才取下一个；微任务队列才会被强制清空。
宏任务队列本身不会被“清空”，它没有周期性清空机制。它的执行是逐个、按序、被动触发的——每次只取一个任务执行，而不是批量清空。
宏任务不是“清空”，而是“逐个取出”
宏任务队列（如 setTimeout、setInterval、UI 渲染、postMessage 等排队的任务）采用先进先出（FIFO）方式管理。事件循环每次只从中取出最老的一个任务执行，其余任务继续等待。这个过程不涉及“清空”或“批量处理”，哪怕队列里有 100 个 setTimeout 回调，也得一个一个来，每个都等前一个彻底结束、微任务全跑完、渲染完成之后才轮到下一个。
- 即使多个 setTimeout(0) 同时到期，仍严格按注册顺序依次执行
- 队列中任务不会因超时而“自动失效”，也不会被跳过或合并
- 没有后台线程在定时扫描或清理队列——只有主线程空闲时才去查队列
执行耗时直接影响后续任务的启动时机
一个宏任务执行时间越长，后续所有任务（包括其他宏任务、微任务、UI 渲染）就被推迟得越久。因为事件循环必须等当前宏任务调用栈完全清空后，才能进入下一阶段。
Javascript Sdk
下载
用于 inference.sh 的 JavaScript/TypeScript SDK，可运行 AI 应用、构建代理、集成 150+ 模型。包名：@inferencesh/sdk（npm install），完整 TypeScript 支持。
- 同步代码卡顿（如 while(true) 或大量计算）会阻塞整个队列，页面无响应
- 长时间运行的宏任务（如解析大 JSON、复杂 canvas 绘制）会让用户交互事件（click、scroll）积压在宏任务队列尾部，造成明显延迟
- 浏览器渲染也被视为宏任务，所以长任务会直接拖慢画面更新频率
真正被“清空”的是微任务队列，不是宏任务队列
容易混淆的一点：常听说“清空微任务队列”，但宏任务队列从不被清空。微任务队列在每个宏任务结束后强制同步执行至为空；而宏任务队列始终处于“待命状态”，只负责排队和单次分发。
- Promise.then、queueMicrotask、MutationObserver 都进微任务队列，且必须一次性执行完
- 宏任务队列里的任务，哪怕注册时间早，也得等前面所有宏任务（含渲染）走完才能执行
- 没有 API 能手动清空宏任务队列——你只能 clearTimeout/clearInterval 主动取消个别任务
实际开发中要注意的节奏感
宏任务之间的间隔，取决于前一个任务的总耗时：同步代码 + 微任务执行时间 + 可能的渲染耗时。这个总和就是下一个宏任务的“等待窗口”。
- 避免在宏任务中做重操作；可拆成 requestIdleCallback 或分片（chunking）处理
- 高频定时器（如 setInterval(16)）不等于每 16ms 执行一次——若前一次还没结束，下一次就会被跳过或堆积
- 用户点击产生的事件回调也是宏任务，若此时主线程正忙，点击响应就会滞后
