定时器回调本身不阻塞主线程，但其内部同步代码会阻塞事件循环；应拆分长任务、用web worker处理cpu密集型逻辑、避免同步忙等和高成本dom/io操作。
定时器回调本身不会阻塞后续代码，但回调内部的同步代码会阻塞后续任务执行。
定时器不阻塞主线程，但回调可能“卡住”事件循环
setTimeout 或 setInterval 注册后，只是把回调函数安排进宏任务队列，并立即返回，主线程继续往下跑——这是非阻塞的。真正影响执行节奏的，是回调函数内部是否包含耗时同步操作。
- 比如
setTimeout(() => { while (Date.now() - start ：定时器准时触发，但回调里这个 2 秒忙等会让调用栈一直不空，后续所有异步回调（包括下一个 setTimeout、Promise.then）都得排队等待。 - 浏览器 UI 渲染、用户点击、其他定时器、fetch 回调，全部被延后，不是被取消，而是“没机会执行”。
- 关键点：阻塞源头不在定时器机制，而在回调中那段同步代码独占了主线程。
常见误判场景：0ms 定时器 ≠ 立即执行
很多人用 setTimeout(fn, 0) 想“让出线程”，但若前序同步代码还没结束，这个 0ms 定时器的回调依然要等；即使前序已结束，它也要排在当前轮次所有微任务之后。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 执行顺序示例：
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 才开始调度。
如何避免回调中的同步阻塞
核心思路是不让任何一段同步逻辑长时间霸占调用栈。
- 把大任务拆成小块，用
setTimeout或queueMicrotask分批执行，每次执行后主动让出控制权。 - CPU 密集型计算移出主线程，例如用 Web Worker 处理数组排序、图像压缩等。
- 避免在 Promise 构造器内写耗时逻辑——
new Promise(resolve => { /* 这里代码是同步执行的 */ })。 - 检查第三方库方法是否含隐式同步阻塞，比如某些深克隆、正则匹配、大型 JSON.parse 在极端输入下可能卡顿。
本质还是单线程资源竞争问题
JavaScript 没有真正的多线程抢占机制。所谓“阻塞”，其实是同步代码执行期间，事件循环无法进入下一轮调度——它不是故意拦着异步任务，而是根本没空看队列。
- 没有“后台线程”帮你跑 while 循环，所有 JS 逻辑都在同一个线程上串行发生。
- 异步 API（如 fetch、setTimeout）只是把任务委托给浏览器底层线程处理，结果回来时仍需回到主线程执行回调。
- 所以优化方向不是“怎么让定时器更快”，而是“怎么让回调更快结束、更早交还控制权”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
