直接砍掉冗余DOM节点比任何JS优化更立竿见影，尤其Canvas/WebGL中混用HTML overlay时，document.querySelectorAll('*').length超2000会因layout重排明显拖慢帧率。
直接砍掉冗余 DOM 节点，比任何 JS 优化都更立竿见影——尤其在 Canvas/WebGL 容器里套 HTML 元素做 overlay 或 UI 的场景，document.querySelectorAll('*').length 超过 2000 就会明显拖慢帧率，不是卡在 JS，是卡在 layout 阶段被浏览器反复重排。
为什么图形容器里的 DOM 特别怕多节点
Canvas/WebGL 渲染本身不依赖 DOM，但一旦混用 HTML overlay（比如 HUD、图例、按钮），DOM 就成了性能瓶颈：浏览器仍需为每个可见节点维护样式树、布局上下文和渲染层；深度超过 3 层时，getBoundingClientRect() 和 offsetTop 这类 API 调用耗时非线性增长；更关键的是，哪怕 overlay 元素 display: none，只要它在 DOM 树里，就参与 CSSOM 构建和继承链回溯。
常见误判是“反正没动，不影响 canvas”，实际测试中，一个 1200 节点的浮动图例面板会让 WebGPU 渲染循环的帧时间从 8ms 拉到 22ms（Chrome DevTools → Rendering → FPS Meter 实测）。
用 CSS 替代 DOM 节点的硬核写法
能不用真实元素，就绝不用。以下写法已在线上高刷图表项目验证：
立即学习“前端免费学习笔记（深入）”；
-
::before/::after生成图标或状态标记，替代<span class="icon"></span> - 间距用
gap（display: grid）或margin，禁用空<div style="height: 8px"></div> - 边框/分隔线优先用
border-bottom或outline + outline-offset，不用<hr>或<div class="divider"></div> - 带图标的输入框写成
<label><svg>...</svg><input></label>，而非三层div嵌套
动态 overlay 元素必须批量插入且脱离流
图形容器常需实时更新 tooltip、坐标提示等 overlay，高频操作极易触发重排风暴：
- 永远用
document.createDocumentFragment()缓存所有新节点，最后单次appendChild()，禁止循环调用 - 插入前临时设父容器
style.display = 'none'，插入完成再恢复，彻底屏蔽中间态 layout - 若 overlay 位置靠 JS 计算（如跟随鼠标），插入后立即读取
offsetWidth等属性会强制同步 layout——改用getComputedStyle(el).width或把计算逻辑移到requestAnimationFrame回调末尾
怎么确认你真减了节点而不是自我安慰
别信代码删了几行，要看真实渲染树：
- Chrome DevTools → Elements 面板，右键最外层容器 →
Copy → Copy outerHTML，粘贴到编辑器里数标签对（注意闭合标签不算独立节点） - 运行
console.log(document.querySelectorAll('#overlay-root *').length)，对比修改前后数字 - 打开 DevTools → Rendering → 勾选
Layout Shift Regions，滚动/悬停时看是否还有意外重排区域亮起
最难的不是写出 grid-template-areas，而是每次加 wrapper 前问一句：“这个 div 的唯一作用，是不是 CSS 已经能干了？”——一旦放过一次，下十个就顺手加了。
