DOM操作是性能瓶颈而非优化手段，频繁读写会触发重排重绘；应避免循环中读取布局属性、批量修改DOM、用requestAnimationFrame节流并优先使用transform等合成属性。
DOM 操作本身就是性能瓶颈，不是优化手段
HTML DOM 本身不会“改善”JS性能；相反，频繁或低效的 DOM 访问和修改，是前端 JS 性能下降的最常见源头之一。浏览器每次读写 document 或元素属性（如 offsetHeight、innerHTML），都可能触发重排（reflow）或重绘（repaint），而这些是同步、阻塞主线程的昂贵操作。
所谓“DOM 优化”，本质是减少无效访问、批量化变更、绕过强制同步布局——不是靠 DOM 提供什么加速 API，而是靠你避开它的坑。
避免在循环中反复读取 offsetTop、getBoundingClientRect() 等布局属性
这类属性会强制浏览器立即计算当前样式与布局（即触发同步 reflow），在循环里调用一次就慢，调用 N 次就是 O(N) 级别的性能灾难。
- ❌ 错误写法：
for (let i = 0; i < items.length; i++) {<br> top += items[i].offsetTop; // 每次都触发 reflow<br>} - ✅ 正确做法：先缓存值，再计算
const tops = Array.from(items, el => el.offsetTop);<br>top = tops.reduce((a, b) => a + b, 0);
- ⚠️ 注意：
getBoundingClientRect()同样强制同步布局，如果只需一次坐标，调用后立刻解构缓存，不要在动画帧或滚动监听里无节制重读
批量 DOM 修改：用 DocumentFragment 或 innerHTML 替代逐个 appendChild
连续多次插入/修改节点时，浏览器可能为每次操作单独排版，开销叠加。把变更集中到内存中完成，再一次性上树，能显著减少 reflow 次数。
立即学习“前端免费学习笔记（深入）”；
- ❌ 多次插入（触发多次 layout）：
listEl.appendChild(li1);<br>listEl.appendChild(li2);<br>listEl.appendChild(li3);
- ✅ 推荐方式 1（
DocumentFragment）：const frag = document.createDocumentFragment();<br>frag.appendChild(li1);<br>frag.appendChild(li2);<br>frag.appendChild(li3);<br>listEl.appendChild(frag); // 仅一次 reflow
- ✅ 推荐方式 2（字符串拼接 +
innerHTML）：listEl.innerHTML = `<li>1</li><li>2</li><li>3</li>`;
适用于结构简单、无需复用节点对象的场景；注意 XSS 风险需自行转义
用 requestAnimationFrame 对齐重排时机，别在 scroll 或 resize 里直接读写 DOM
滚动或窗口缩放时，事件触发频率极高（每秒数十次），若其中包含 offsetHeight 读取 + style.left 修改，等于每帧都制造 reflow + repaint，必然卡顿。
- ✅ 正确节奏：
– 在事件回调中只记录状态（如lastScrollY）
– 用requestAnimationFrame节流，在下一帧开始时统一读取 + 计算 + 写入
– 示例：let pending = false;<br>window.addEventListener('scroll', () => {<br> if (!pending) {<br> pending = true;<br> requestAnimationFrame(() => {<br> const pos = window.scrollY;<br> el.style.transform = `translateY(${pos}px)`;<br> pending = false;<br> });<br> }<br>}); - ⚠️ 关键点：
transform和opacity属于合成属性，修改它们通常不触发 reflow，比直接改top/left安全得多
真正影响性能的从来不是 DOM API 本身多慢，而是你有没有意识到：每一次属性读取都可能拉起整个渲染管线，每一次节点插入都可能让浏览器停下脚步重算布局。这些细节不写进规范，但写在每一帧的耗时火焰图里。
