DOM操作本身不拖慢JS，但频繁低效访问（如循环中多次调用getElementById）会因重复遍历、强制同步布局和重排开销导致卡顿；应缓存引用、批量更新并避免读写布局属性。
DOM 操作本身不拖慢 JS，但你写的代码会——问题出在读写时机、频率和方式，而不是 DOM 存在本身。
频繁调用 document.getElementById 为什么卡
每次调用都触发一次完整 DOM 树遍历 + ID 匹配，不是缓存查找。在循环或高频回调（如 scroll、mousemove）里反复写 document.getElementById('modal')，等于反复搜索上万节点的树。
- ✅ 正确做法：查一次，存变量，后续直接用
const modal = document.getElementById('modal') - ⚠️ 常见错误：在
for循环里每次都调用，尤其配合offsetTop或getBoundingClientRect() - ? 性能影响：实测在中端设备上，100 次重复调用比缓存慢 3–8 倍，且可能引发“布局抖动”
innerHTML 和 createElement 哪个快
没有绝对答案，只看场景。浏览器对两者都有深度优化，但副作用和触发时机完全不同。
- ✅
innerHTML更适合纯展示型批量插入（如搜索结果列表），V8/Blink 对字符串解析有加速，插入 1000 个<div></div>通常快 2–5 倍 - ⚠️ 但会清空原有事件监听器、丢失
<input>的用户输入值、重置表单状态 - ✅
createElement+DocumentFragment更安全可控，适合含交互逻辑的动态节点（如带按钮、需绑定事件的卡片） - ⚠️ 单独用
appendChild循环 100 次，会触发 100 次潜在重排；必须先塞进DocumentFragment再一次性挂载
读写布局属性为什么会拖垮主线程
像 offsetHeight、getComputedStyle()、scrollLeft 这类 API 是“强制同步布局”的开关——只要读一次，浏览器就得立刻完成所有待处理的样式计算、重排（reflow），再返回结果。
立即学习“前端免费学习笔记（深入）”；
- ❌ 错误模式：
for (let i = 0; i → 每轮都强制刷新布局 - ✅ 正确模式：“读-写分离”：先遍历一遍缓存所有
offsetHeight到数组，再遍历一遍统一写入style - ? 小技巧：临时把元素设为
display: none再读尺寸，可避免连续触发重排（读完记得恢复）
事件委托真的省性能吗
不一定。委托能减少监听器数量，但滥用反而增加 CPU 开销。
- ✅ 合理场景：在
<ul class="list">上监听click，用e.target.classList.contains('item-btn')判断目标 - ❌ 高危操作：挂在
document上，又在 handler 里反复调用e.target.closest('.action')或e.target.parentElement.querySelector('.meta') - ? 性能关键点：委托层级越浅越好（优先选最近公共父级），匹配逻辑越简单越好（
classList.contains比matches()快） - ⚠️ 高频事件（
scroll、mousemove）必须加throttle或requestAnimationFrame节流，否则 JS 主线程直接被占满
真正卡顿的从来不是 DOM 节点本身，而是你在主线程里反复打断浏览器的渲染节奏——读布局、改样式、插节点、再读布局……这种“一步一停”的操作，才是重排重绘泛滥的根源。
