dom节点超2000会因layout重排显著拖慢帧率，实测1200节点图例使webgpu帧时间从8ms升至22ms；深层嵌套（>5层）导致offsettop等api耗时非线性增长，display: none元素仍参与cssom构建。
DOM节点数超2000时layout重排会明显拖慢帧率
Canvas/WebGL容器里混用HTML overlay，document.querySelectorAll('*').length一旦超过2000，帧率就肉眼可见掉帧——不是JS卡，是浏览器在layout阶段反复重排。实测中一个1200节点的浮动图例面板，能把WebGPU渲染循环从8ms拉到22ms。
深层嵌套（>5层）会让offsetTop、getBoundingClientRect()这类API调用耗时非线性增长；更隐蔽的是，哪怕元素display: none，只要还在DOM树里，就参与CSSOM构建和继承链回溯。
- 用
console.dir(document.body)查childNodes.length，超200就该警惕 - 打开DevTools → Elements → 右键任意节点 → “Show DOM properties”，看
depth字段，超6层必须拆 - 禁用空
<div style="height: 8px"></div>，改用gap或margin
高频更新时innerHTML +=拼接会持续泄漏DOM节点
每次执行el.innerHTML += htmlString，浏览器都会销毁旧子树、重建新节点，但旧节点若被JS变量引用，就会变成detached DOM tree，长期驻留内存。Chrome Memory面板里“Detached DOM tree”体积持续上涨，基本就是这个原因。
尤其在滚动日志、实时拓扑图这类每秒更新多次的场景，反复拼接+未清理引用，几小时内JS堆就能涨到85%以上，触发performance.memory.usedJSHeapSize > 0.85 * performance.memory.totalJSHeapSize警告。
- 改用
document.createDocumentFragment()批量组装，最后单次appendChild() - 列表类更新，超500条必须启用虚拟滚动（如
IntersectionObserver+display: none切换） - 移除元素前，手动解绑事件：
el.removeEventListener('click', handler)，别依赖GC
Shadow DOM里直接赋值shadowRoot.innerHTML会触发全量重绘
在attributeChangedCallback或render里写this.shadowRoot.innerHTML = template，属性变一次就销毁重建整个子树——事件监听器重绑、样式重计算、布局重排全来一遍，完全违背增量更新原则。
这不是“写法不优雅”的问题，是性能硬伤：实测单次更新耗时从0.8ms飙升至12ms，高频调用直接压垮主线程。
- 优先用Lit的
html模板函数+render()做差异更新 - 必须字符串插入时，先用
DocumentFragment组装再挂载，禁止循环appendChild() - 用
shouldUpdate拦截无关属性变更（如只改loading状态却不影响结构时返回false）
模板残留和未调用JS会悄悄吃掉CPU和内存
复制粘贴来的HTML模板常带一整套轮播图、折叠菜单逻辑，哪怕页面里根本没对应DOM，这些JS照样执行、绑定resize监听、注册DOMContentLoaded回调——它们不报错，但持续占用内存、触发无意义重排。
覆盖率分析（Command+Shift+P → “Coverage”）显示大量CSS规则灰掉、JS函数从未执行，就是典型信号。
- 全局搜索
document.addEventListener、new Image()、fetch(，定位未使用模块 - 删掉所有
{{、{%、
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
