定时器回调本身不阻塞主线程，但其内部同步代码会阻塞事件循环；应拆分长任务、用Web Worker处理CPU密集型逻辑、避免同步忙等和高成本DOM/IO操作。
定时器回调本身不会阻塞后续代码，但回调内部的同步代码会阻塞后续任务执行。
定时器不阻塞主线程，但回调可能“卡住”事件循环
setTimeout 或 setInterval 注册后，只是把回调函数安排进宏任务队列，并立即返回，主线程继续往下跑——这是非阻塞的。真正影响执行节奏的，是回调函数内部是否包含耗时同步操作。
- 比如
setTimeout(() => { while (Date.now() - start ：定时器准时触发，但回调里这个 2 秒忙等会让调用栈一直不空，后续所有异步回调（包括下一个 setTimeout、Promise.then）都得排队等待。 - 浏览器 UI 渲染、用户点击、其他定时器、fetch 回调，全部被延后，不是被取消，而是“没机会执行”。
- 关键点：阻塞源头不在定时器机制，而在回调中那段同步代码独占了主线程。
常见误判场景：0ms 定时器 ≠ 立即执行
很多人用 setTimeout(fn, 0) 想“让出线程”，但若前序同步代码还没结束，这个 0ms 定时器的回调依然要等；即使前序已结束，它也要排在当前轮次所有微任务之后。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 执行顺序示例：
console.log(1); Promise.resolve().then(() => console.log(2)); setTimeout(() => console.log(3), 0); console.log(4);输出是1 → 4 → 2 → 3。 - 说明：同步代码（1 和 4）先执行；接着清空微任务队列（2）；最后才取一个宏任务（3）。
- 如果 1 和 4 中夹着一段 100ms 的 while 循环，那 2 和 3 都会整体延后约 100ms 才开始调度。
如何避免回调中的同步阻塞
核心思路是不让任何一段同步逻辑长时间霸占调用栈。
立即学习“Java免费学习笔记（深入）”；
- 把大任务拆成小块，用
setTimeout或queueMicrotask分批执行，每次执行后主动让出控制权。 - CPU 密集型计算移出主线程，例如用 Web Worker 处理数组排序、图像压缩等。
- 避免在 Promise 构造器内写耗时逻辑——
new Promise(resolve => { /* 这里代码是同步执行的 */ })。 - 检查第三方库方法是否含隐式同步阻塞，比如某些深克隆、正则匹配、大型 JSON.parse 在极端输入下可能卡顿。
本质还是单线程资源竞争问题
JavaScript 没有真正的多线程抢占机制。所谓“阻塞”，其实是同步代码执行期间，事件循环无法进入下一轮调度——它不是故意拦着异步任务，而是根本没空看队列。
- 没有“后台线程”帮你跑 while 循环，所有 JS 逻辑都在同一个线程上串行发生。
- 异步 API（如 fetch、setTimeout）只是把任务委托给浏览器底层线程处理，结果回来时仍需回到主线程执行回调。
- 所以优化方向不是“怎么让定时器更快”，而是“怎么让回调更快结束、更早交还控制权”。
