DOM操作是JS性能下降的主因之一，因其触发重排重绘且JS与GUI线程互斥；应减少跨线程查询、缓存DOM引用、用静态NodeList替代实时集合、合理委托事件。
DOM 本身不会改善 JavaScript 性能；相反，**频繁或低效的 DOM 操作是 JS 性能下降的主因之一**。关键不在“用不用 DOM”，而在“怎么用”。
浏览器中 JS 引擎线程和 GUI 渲染线程互斥，每次读写 document、调用 getElementById、修改 style 或插入节点，都可能触发重排（reflow）或重绘（repaint）。这些开销远大于纯 JS 运算。
下面直说几个真实开发中高频踩坑点和对应解法：
为什么 document.getElementById 每次调用都慢？
它不是“查缓存”，而是每次向渲染线程发起同步查询请求。尤其在循环里反复写 document.getElementById('list')，等于反复跨线程通信。
- ✅ 正确做法：查一次，存变量 ——
const list = document.getElementById('list'); - ⚠️ 注意：
getElementsByClassName返回的是实时集合（HTMLCollection），每次访问.length都会重新遍历 DOM，比querySelectorAll（返回静态 NodeList）更耗性能 - ❌ 错误模式：
for (let i = 0; i —— 每次循环都重算长度
innerHTML 和 createElement 哪个更快？
没有绝对答案，取决于场景和浏览器。Chrome 下 createElement + appendChild 批量插入常优于 innerHTML；Firefox 则反之。但安全性和可维护性上，createElement 明显占优。
- ✅ 插入大量静态结构（如模板 HTML 字符串）：用
innerHTML可读性高，但必须确保内容可信，否则有 XSS 风险 - ✅ 动态拼接、含用户输入：优先用
document.createElement+textContent，避免解析 HTML - ✅ 真正的性能关键点：是否用了
document.createDocumentFragment()—— 它把多次 DOM 修改收拢成一次插入，减少重排次数
为什么改 10 次 style 属性比改 1 次慢 10 倍？
因为每次写 el.style.color、el.style.fontSize 都可能触发强制同步布局（forced synchronous layout），浏览器必须立刻计算当前样式并回滚渲染队列。
- ✅ 推荐：用 CSS 类控制样式变化 ——
el.classList.add('active')，所有变更由 CSSOM 统一处理 - ✅ 若必须内联样式，合并写入：
el.style.cssText = 'color: red; font-size: 14px;'（注意会覆盖原有style） - ❌ 避免混着读写：
console.log(el.offsetHeight); el.style.height = '200px';—— 这种组合极易引发强制重排
事件绑定太多导致内存泄漏？
给每个 li 单独绑 click，100 个就是 100 个监听器。不仅初始化慢，后续移除节点时若没手动 removeEventListener，就容易泄漏。
立即学习“前端免费学习笔记（深入）”；
- ✅ 一律用事件委托：
parent.addEventListener('click', e => { if (e.target.matches('.item')) { ... } }) - ✅ 父容器尽量选稳定节点（如
#list），别用document或body—— 事件冒泡路径越长，响应延迟越明显 - ✅ 动态增删子元素完全无感，无需重绑
