document.querySelectorAll('*').length 超过 2000 是低端设备即将崩溃的明确阈值，首屏节点须 ≤500；需用 DOMPurify 清洗富文本、避免深层嵌套、分帧渲染并监控内存使用。
document.querySelectorAll('*').length 超过 2000 就该干预
这不是性能变慢的信号，而是低端设备（如 2GB RAM 的 Android 12/13）即将崩溃的明确阈值。Blink 渲染器在 layout 阶段会因堆内存耗尽被系统强制杀进程，现象是白屏、静默失败或直接抛 RangeError: Maximum call stack size exceeded，而非 JS 报错。
- 首屏节点必须 ≤500 —— 实测 SPA 冷启动后 3 秒内内存就可能突破 300MB
- 整页节点 >2000 时，
appendChild可能直接失效，尤其在 SSR 模板中大量空 wrapper（如<div class="container"><div class="row"><div class="col">）会快速放大开销 - 用
document.querySelectorAll('*').length在 DevTools Console 快速验证真实节点数，别信“看起来没卡”
v-html 或 innerHTML 插入前必须用 DOMPurify.sanitize()
服务端返回的富文本常含注释、冗余空格、嵌套无意义标签，未经清洗直接插入会使节点数翻倍。例如一个带格式的段落，原始 HTML 可能生成 15 个节点，而清洗后只剩 3–4 个。
-
DOMPurify.sanitize()不仅防 XSS，还能剔除 90% 以上无语义节点（如空<span></span>、多余<font>） - 避免用
innerHTML = ''清空再重赋值——这会触发两次 DOM 构建，比remove()更耗内存 - 若无法引入 DOMPurify，至少做最小清洗：
html.replace(/<!--[\s\S]*?-->/g, '').replace(/\s+/g, ' ').trim()，但效果有限
深层嵌套 div 是内存黑洞，优先用 flex + inline-block 替代
每个 DOM 节点至少占 1–2 KB 内存（含样式、布局、事件监听器缓存），5 层嵌套的 <div> 堆叠，单节点开销可达 10 KB。更糟的是，深层结构会放大 CSSOM 计算和事件委托链的间接成本。
- 把
<div><div><div><p>文本</p></div></div></div>改成<div style="display:inline-block"><p>文本</p></div> - 布局类容器（如卡片、列表项）用
display: flex+gap，而非靠多层div对齐 - 移除所有仅用于“撑开空间”的空
<div>，改用padding或gap
动态渲染必须分帧，requestIdleCallback 是唯一安全入口
一次性插入数百节点会阻塞主线程，导致 layout 阶段卡死。不能靠 setTimeout 或 Promise.then 模拟分帧——它们不保证空闲时机，仍可能挤占渲染帧。
立即学习“前端免费学习笔记（深入）”；
- 用
requestIdleCallback批量注入，每次最多处理 20–30 个节点 - 配合
document.createDocumentFragment()缓存片段，避免反复触发 reflow - 当
performance.memory?.usedJSHeapSize > 0.85 * performance.memory.jsHeapSizeLimit时，主动降级：跳过动画、关闭非关键样式计算、暂停后续帧
节点数不是越少越好，而是要在可维护性与内存压力间找临界点。真正危险的不是“写了多少行 HTML”，而是“浏览器构建了多少个对象并长期持有”。querySelectorAll 数一次，比写十遍优化技巧都管用。
