JavaScript同步长任务阻塞主线程导致渲染卡顿；因JS执行与UI渲染共用主线程，超16.6ms任务即掉帧，超50ms即被Chrome标记为长任务并引发明显卡顿。
JavaScript 事件循环本身不“阻碍”渲染，真正卡顿的根源是：同步代码长时间霸占主线程，导致浏览器根本没机会执行渲染任务。
主线程是单行道，JS 和渲染共用一条路
浏览器的 UI 渲染（布局、绘制）和 JavaScript 执行都在同一个主线程上。事件循环只是调度机制——它按顺序从任务队列里取任务来跑。但只要一个同步任务（比如大循环、JSON.parse超大字符串、深度遍历树）运行超过 16.6ms（一帧时间），后续的渲染任务就会被压在队列里干等。
结果就是：用户操作有延迟、动画掉帧、滚动卡涩，甚至看起来像“假死”。
长任务 >50ms 是卡顿的明确信号
Chrome 把持续占用主线程超过 50ms 的任务标记为“长任务（Long Task）”，这已远超一帧预算，必然引发可感知卡顿：
立即学习“Java免费学习笔记（深入）”；
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
- 一个 for (let i = 0; i 很可能耗时几百毫秒
- JSON.parse() 一个 10MB 的响应体 会同步阻塞主线程数十毫秒
- 未分片的 Array.map().forEach().filter() 处理上万条数据
这些不是异步问题，而是同步执行不可分割，事件循环只能等它彻底结束，才能调度下一帧渲染。
微任务过多也会间接拖慢渲染
虽然 Promise.then、queueMicrotask 属于微任务，不直接阻塞宏任务，但它们有“清空队列”特性：每次宏任务结束后，会一口气执行完所有待处理的微任务。
如果形成微任务链（比如递归调用 then 或嵌套上百层 resolve），会导致：
- 渲染任务被持续延后，因为微任务队列不空，事件循环不会进入下一轮宏任务，也就不触发渲染
- 内存持续增长，GC 压力增大，进一步加剧卡顿
你以为异步就安全？这些写法照样卡
很多开发者误以为加了 setTimeout 或 Promise 就万事大吉，其实错误用法仍会制造隐性长任务或调度风暴：
- 递归 setTimeout 没退出条件：任务不断入队，CPU 和调度开销飙升
- 循环中创建大量 setInterval：上千个定时器后续集中触发，瞬间涌出大量宏任务
- 高频事件回调不做节流：resize、input、scroll 触发太密，微任务/宏任务堆积如山
这些不是事件循环坏了，而是任务调度失衡，让主线程始终处于高负载状态，渲染自然被挤占。
