dom解析卡顿主因是构建完整dom树的同步阻塞，而非加载慢；节点超10万时chrome明显降速，需用documentfragment批量插入、流式解析或服务端切片优化。
DOM节点过多直接卡住解析线程，不是加载慢而是构建慢
浏览器解析HTML是单线程同步过程，当DOM节点数超过10万级（比如2800+行HTML、嵌套过深的列表或表格），document.createElement和树挂载本身就会吃掉几十甚至上百毫秒。这不是网络下载慢，也不是JS执行慢，而是DOM树构建阶段就已超时——你看到的“白屏”或“页面不动”，其实是主线程被DOM解析死锁了。
常见现象包括：DOMContentLoaded迟迟不触发、Lighthouse报“Reduce initial JavaScript execution time”但实际没JS、滚动立刻卡顿且requestIdleCallback几乎不回调。
- DOM节点数量 > 50,000 时，Chrome 开始明显降速；> 100,000 时，部分低端设备可能直接假死
- 避免用
innerHTML +=拼接大量HTML，每次赋值都会触发完整重解析 - 服务端渲染（SSR）若输出未分块的巨型HTML，问题会更早暴露
虚拟滚动不是万能解，关键在“释放时机”和“缓存粒度”
很多方案只做“可视区域渲染”，但快速滚动时因来不及创建新节点而留白，或因释放太激进而导致内存泄漏——比如子节点的removeChild没清掉事件监听器，或nodeMap里残留已销毁节点的引用。
真实有效的做法是：提前加载上下两屏（而非仅一屏），释放阈值设为“超出视口 1.5 倍容器高度”，并用WeakMap管理节点状态，避免强引用阻止GC。
- 别用
display: none代替移除——它仍参与样式计算和布局，内存不释放 - 用
document.createDocumentFragment()批量插入，比逐个appendChild快5–10倍 - 滚动监听必须用
passive: true，否则preventDefault会强制同步阻塞主线程
XML/JSON大文件加载失败，本质是浏览器不支持流式DOM构建
如果页面靠XMLHttpRequest或fetch加载几百MB的XML/HTML片段再DOMParser.parseFromString，必然崩溃。这不是内存不够，而是浏览器强制要求“全文载入后才能建树”——中间任何阶段都无法中断或分片。
可行路径只有两条：服务端改用分页或NDJSON，或客户端放弃DOMParser，改用XMLParser配合ReadableStream边读边吐节点。
-
DOMParser对5MB以上XML已极不稳定，10MB基本必崩 -
XMLParser需手动处理startElement/text事件，无法回溯，适合“只读+顺序处理”场景 - 若必须保留DOM结构，唯一妥协是服务端切片：按
<item></item>边界切分成多个小响应，前端串行parseFromString
html2canvas截大DOM卡死，核心是它默认遍历全部节点
html2canvas默认从根节点开始递归抓取，遇到display: none、visibility: hidden、<script></script>、注释节点全不跳过，1000个节点就可能吃掉450ms+。这不是截图逻辑慢，是它把DOM树当黑盒暴力遍历。
真正提速的关键是缩小输入面：指定最小容器、过滤干扰节点、禁用非必要样式计算。
- 永远不要传
document.body，改用document.getElementById('report-section') - 配置
ignoreElements: (el) => el.hasAttribute('data-no-capture')标记可忽略区域 - 截图前临时移除
style标签和link[rel="stylesheet"]，避免重复解析CSSOM
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
