SVG节点拖慢querySelectorAll是因为每个<svg>构建完整子树并计入全局DOM总数，100个SVG导致100倍路径扫描；<use>复用可减少90%以上可遍历节点；缺失viewBox、width/height缩放无preserveAspectRatio、循环调用getCTM()或getBBox()会触发强制同步布局；加pointer-events:none可切断事件捕获链路提升性能。
嵌套 SVG 本身不增加 DOM 遍历开销，但每个 <svg> 标签都会作为独立子树插入 DOM，触发额外的样式计算、布局和重排——真正拖慢的是“数量”和“写法”，不是“嵌套”本身。
为什么 <svg> 节点会让 querySelectorAll 变慢
浏览器对每个 <svg> 都构建完整 DOM 子树，包括所有 <path>、<circle>、<g> 等子节点。这些节点全部计入全局 DOM 节点总数，并参与 CSS 选择器匹配流程。
-
document.querySelectorAll('svg path')每次都要遍历所有<svg>容器下的全部子元素，100 个 SVG 就是 100 倍路径扫描量 - 若 SVG 内含
<g transform="...">嵌套，浏览器仍需逐层解析 transform 属性以确定最终坐标，即使你只读offsetTop - 深层 SVG（如
<div><svg><g><g><path>）会放大 DOM 深度效应：实测深度从 4 升到 8，getComputedStyle(path)耗时翻倍
<use> 复用比内联 SVG 节省多少遍历成本
用 <symbol> + <use> 后，DOM 中只保留轻量 <use> 节点，真实图形结构只存一份在 <defs> 或隐藏 <svg> 里——这直接砍掉 90% 以上可遍历节点。
- 100 个图标内联：生成约 1200 个 DOM 节点（含
<svg>、<g>、<path>） - 100 个图标用
<use href="#icon-home">：仅 100 个<use>节点 + 1 份<symbol>结构（不参与遍历） -
document.getElementById('icon-home')返回<symbol>，但document.querySelector('use')不会递归进其引用内容——这是关键隔离点
哪些 SVG 写法会让 document.querySelectorAll 触发强制同步布局
只要读取任何依赖几何信息的属性（哪怕只是查个是否存在），浏览器就可能为整个 SVG 子树执行 layout。常见诱因集中在坐标与缩放逻辑上。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- 缺失
viewBox：浏览器无法确定逻辑坐标系，每次访问getBBox()或getScreenCTM()都强制回溯重算 - 用
width/height缩放但没设preserveAspectRatio：触发重排且不同设备表现不一致 - 在循环中调用
use.getCTM()或path.getBBox()：每个调用都可能刷新样式树+布局树 - 给
<svg>设font-size或filter：强制创建合成层，后续所有 DOM 查询都绕不开该层渲染上下文
SVG 容器要不要加 pointer-events: none
要，尤其当它只作静态底图或装饰用途。这不是为了“禁用点击”，而是切断浏览器对整个子树的事件捕获链路，避免隐式性能损耗。
- 默认下，每个
<path>都注册了事件监听准备（即使没绑定 handler），浏览器需维护 hit-testing 树 -
pointer-events: none让整棵 SVG 子树退出事件系统，document.elementFromPoint()不再遍历其内部节点 - 需要交互时，改用
svg.getScreenCTM()+inverseTransform手动映射坐标，只对命中目标做精确查询 - 注意：该样式不影响
focus()或 ARIA 属性读取，无障碍支持不受损
真正难优化的从来不是 SVG 语法本身，而是设计稿直出文件里那些未清理的 <g transform="translate(0,0)">、冗余 <defs> 和万级 path 数据——它们让 DOM 遍历变成线性扫描噩梦，而工具链往往默认放过这类“合法但低效”的 XML。
