DOM本身不拖慢JS性能，但JS操作方式决定性能表现：频繁读写布局属性会触发强制重排/重绘，需读写分离、缓存引用、批量处理并优先使用transform等合成属性。
HTML DOM 不需要 JS 性能，但 JS 操作 DOM 的方式会直接决定性能表现。 不存在“DOM 要求 JS 多快”，而是你每次调用 getElementById、读取 offsetHeight、设置 innerHTML，都在触发浏览器底层的同步计算——这一步卡不卡，取决于你怎么写代码，而不是 DOM 本身有多“重”。
为什么 document.getElementById 会变慢？
它本身是 O(1) 查找，但前提是 ID 真实存在且唯一。问题常出在误用场景：
- 在
scroll或mousemove回调里反复调用document.getElementById('header')—— 每次都走一次树遍历，不是缓存失效，是根本没缓存 - ID 值拼错或动态生成（如
'item-' + i）导致匹配失败，浏览器仍要搜完整棵树 - 在 Shadow DOM 内部调用全局
document.getElementById，永远找不到，白耗 CPU
正确做法：查一次，存变量，后续直接用。
const headerEl = document.getElementById('header');
// 后续所有操作都基于 headerEl，不再查 document
哪些 DOM 属性读取会强制重排？
只要涉及布局计算的属性，读取即触发同步重排（reflow），尤其在循环中极其危险：
立即学习“前端免费学习笔记（深入）”；
-
offsetTop、offsetLeft、offsetWidth、offsetHeight -
scrollTop、scrollLeft、scrollWidth、scrollHeight -
clientTop、clientLeft、clientWidth、clientHeight -
getBoundingClientRect()和getComputedStyle(el)（Safari 尤其保守）
关键原则：把所有这类读操作集中做，批量缓存结果；所有写操作（如改 style.left、className）另起一批做，避免“读-写-读-写”交错。
innerHTML vs createElement，哪个更快？
没有绝对答案，看量级和上下文：
- 插入 ≤10 个节点：
createElement+appendChild在 Chrome 中实测快 10%~20%，跳过 HTML 解析开销 - 插入几十到上百个节点：用
DocumentFragment批量 append，再一次性挂载，避免中间态重排 - 纯文本内容：无条件选
textContent，它不解析 HTML、不执行脚本、不重建子树、自动转义 - 注意陷阱：
innerHTML = '...'会清空并重建整个子树，表单元素状态（如<input value="user">的当前输入值）直接丢失
事件绑定位置不当也会拖慢 JS
事件委托本身不慢，但常见错误让性能雪上加霜：
- 把
click委托到document或body—— 冒泡路径太长，每个 click 都要穿透整个 DOM 树 - 委托容器层级过深（比如挂到一个 5 层嵌套的
<div class="list-wrapper">），且内部节点频繁增删，导致事件路径重建开销上升 <li>用 <code>e.target.matches('.btn')判断目标，比e.target.classList.contains('btn')慢 3~5 倍（前者要解析 CSS 选择器） - 没对
scroll/resize加throttle，JS 主线程被持续占满，页面直接冻结
真正影响性能的，从来不是“用了 DOM”，而是你在哪一帧、以什么顺序、访问了哪些属性、触发了多少次重排。这些细节不会报错，但会让用户明显感觉到卡顿——而且很难定位。
