万级dom卡顿主因是节点“存活权重”过高和结构嵌套过深；dom深度超3层即引发layout耗时非线性上升，超6层时getcomputedstyle等api耗时翻倍，须压平至3层内并用css替代冗余包裹。
万级 DOM 节点卡顿不是数据量问题，而是你让浏览器把所有节点都当“活跃渲染单元”来对待——真正要砍的不是节点数，是节点的“存活权重”和“结构税”。
DOM 深度超过 3 层时 layout 耗时非线性飙升
浏览器每多一层嵌套，就要多做一次样式继承回溯、布局上下文创建、属性链查找。深度 >6 时 getComputedStyle() 耗时可能翻倍，document.querySelector('.a .b .c .d') 这类选择器匹配失败成本极高。
- 别信“语义化必须套三层 div”，
<article><header><h1></h1></header></article>是语义，<div><div><div> <p> 是债务</p> <li>表单控件常见冗余：<code><div><div><div><input></div></div></div>→ 改用<label class="input-group"><input></label>，靠display: flex和gap控制间距 - 卡片类结构能压到 1 层就别用
card-inner/card-body套娃；用::before伪元素画分隔线，不用额外<div class="divider"> <li>验证是否真压平：Chrome DevTools → Elements 面板右键任意节点 → <strong>Show DOM properties</strong> → 查看 <code>depth值，超过 6 就得重构 - 匿名函数绑定的事件无法解绑，改用命名函数或事件委托（但代理容器不能意外 retain 子节点）
- Canvas tooltip 类场景常见陷阱：鼠标移入生成
<div class="tooltip">，移出调 <code>remove()—— 若该 div 被闭包捕获（如在requestAnimationFrame回调中持续读取offsetTop），内存永不释放 - 避免
innerHTML = ''清空容器：它强制重排且无法控制释放节奏；改用while (container.firstChild) container.removeChild(container.firstChild)或现代container.replaceChildren() - 池大小设为可视区域行数 × 2～3（如视口显示 20 行，池配 40～60 个
<tr>）；过大拖慢 GC，过小导致频繁新建<li> <code>recover()必须清空textContent和innerHTML，否则旧数据残留引发错行；同时重置node.dataset.key = ''和node.style.cssText = '' - 事件监听器不在
createFn里绑，而是在取出后按需绑定，回收前必须removeEventListener解绑 - 固定行高是硬要求：
rowHeight设死（如 48），缓冲区bufferCount至少为Math.ceil(viewportHeight / rowHeight) + 2，撑高容器的phantomHeight必须严格等于totalCount * rowHeight - 若 HTML 含
<img onerror="this.src='/fallback.png'">，错误回调里的this会隐式持有 DOM 引用，即使节点被v-html替换也不释放 - 禁止在
v-html内容里写内联onclick="doSomething()"；统一用事件委托 +data-*标识，组件卸载时手动解绑 - 第三方富文本（如 TinyMCE 输出）常带隐藏
<script></script>或iframe，务必用DOMPurify.sanitize()过滤，否则 script 执行后可能挂全局变量 - 大屏监控场景下，
v-html每秒更新，建议加节流：用requestAnimationFrame包裹更新逻辑，避免连续触发 layout
删掉 <div> 嵌套能降内存，但关键在“删完还剩什么”<p>每个 DOM 节点至少占 1–2 KB（含样式、事件、布局缓存），深层嵌套还会放大事件监听器和计算样式缓存的间接开销。但更致命的是：节点删了，JS 引用没断，它还在堆里活着。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill4293" title="Doc To HTML"><img
src="https://img.php.cn/upload/skill/000/000/081/178998486916110.jpg" alt="Doc To HTML" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill4293" title="Doc To HTML" class="overflowclass">Doc To HTML</a>
<p class="overflowclass">使用 MinerU 文档处理引擎将 Word 文档（.doc、.docx）转换为保留结构和格式的干净 HTML。</p>
</div>
<a rel="nofollow" href="/xiazai/skill4293" title="Doc To HTML" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
<ul>
<li>
<code>element.remove() 只摘树，不销毁；必须配对 node = null、removeEventListener('click', handler)
万级表格/列表必须用 DOM 复用池，而非虚拟滚动 alone
虚拟滚动只解决“不渲染不可见行”，但滚动时仍高频创建/销毁节点 —— 每次 document.createElement('tr') 都触发完整渲染流水线（构建 + 样式 + layout + paint），GC 压力爆炸。
v-html 渲染巨量 HTML 时的内存泄漏高危点
v-html 直接插入字符串，绕过 Vue 的响应式追踪，但不会自动清理内联事件、onerror 回调、第三方脚本注入的全局引用 —— 这些都是静默内存黑洞。
最常被忽略的不是“怎么删 DOM”，而是“删完 JS 里还留着几条引用链”——尤其在 Canvas + DOM 混合渲染、实时日志流、SSR 注入 wrapper 等场景，那些看不见的闭包和第三方库缓存，才是内存缓慢爬升的真凶。
