确认长任务阻塞dom解析需查看chrome devtools performance面板main线程：若parse html蓝条被≥50ms的evaluate script黄条截断，即为主线程被独占阻塞。
怎么确认是长任务卡住了DOM解析
直接看 Chrome DevTools Performance 面板的 Main 线程：如果 Parse HTML 蓝条被中间插入的 Evaluate Script 黄条硬生生截断，且黄条持续时间 ≥50ms，基本就是它在阻塞。这种阻塞不是“慢”，而是主线程被独占——连 postMessage 都收不到，document.getElementById("xxx") 返回 null 很可能只是因为你调得太早，DOM 根本没机会构建完。
哪些代码容易触发解析阶段的长任务
常见错误不是写错语法，而是把耗时逻辑塞进 DOM 构建流程里：
- 在
DOMContentLoaded回调里一口气遍历 10 万个节点并批量设置style或dataset - 用
innerHTML = hugeString替换大段结构，之后立刻调用getBoundingClientRect() - 在
input事件中反复执行未节流的解析函数，用户连敲 5 次就积压 5 个同步任务 - 循环中频繁读写布局属性（如
offsetHeight后紧跟style.width），触发强制同步布局
如何用 PerformanceObserver 捕获真实长任务
PerformanceObserver 是唯一能实时捕获运行中长任务的方式，但必须在页面早期注册，否则首屏关键任务就漏了：
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
if (entry.duration >= 50) {
console.warn('Long Task:', entry.duration.toFixed(1) + 'ms', entry.name, entry.attribution);
}
});
});
observer.observe({ entryTypes: ['longtask'] });
注意：attribution 在跨域 iframe 或某些 script 加载方式下为空，此时只能靠 name（如 "self"）粗略定位来源；Safari 目前不支持该 API。
切片不是加个 setTimeout 就完事
真正有效的切片得匹配场景、控制粒度、保留上下文：
- 基于时间片：用
performance.now()监控已耗时，每处理 100 个节点就检查是否超 5ms，超则用requestIdleCallback或setTimeout(fn, 0)让出控制权 - 基于节点数：适合结构清晰的数据（如表格行），每次只处理
Math.min(50, remaining)行，用闭包保存currentIndex和数据引用 - 基于微任务：用
Promise.resolve().then()替代setTimeout，避免宏任务调度延迟；但它不保证“下一帧”，只保证当前宏任务结束后立即执行
最常被忽略的是：切片后必须显式保留状态（比如当前处理到第几项），否则重入时会从头开始，反而更慢。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
