DOM性能瓶颈源于不当操作模式而非DOM本身
提起DOM操作，很多开发者第一反应就是“性能杀手”。这话对，但也不全对。实际上，真正的瓶颈往往不是DOM API本身，而是我们使用它们的方式。频繁的读写、低效的遍历，尤其是无意中触发的强制重排与重绘，才是拖慢执行速度的幕后黑手。所以说，关键不在于能不能用DOM，而在于怎么用。
为什么 document.getElementById 比 document.querySelectorAll 快得多
这就好比去图书馆找书：getElementById相当于直接查阅按书名精确编号的索引卡，一步到位；而querySelectorAll则更像是把整个图书馆的书翻一遍，看看有没有符合你描述的那本。技术上，前者依赖浏览器内部为ID维护的哈希映射，时间复杂度接近常数级O(1)；后者则必须遍历整个DOM子树，走一遍完整的选择器引擎进行匹配，即便你写的只是#id，也免不了这层额外的解析开销。
- 能用
document.getElementById('foo')就别用document.querySelectorAll('#foo')[0]，尤其在循环或高频触发的回调里，这点差异会被放大。 querySelector系列的优势在于动态选择器的灵活性，但为了一个静态的ID或类名去迁就它，就有些得不偿失了。- 经验表明，如果同一个元素会被多次用到，务必缓存到变量里。
const btn = document.getElementById('submit');这句简单的代码，可能就是避免重复开销的关键。
innerHTML 批量插入 vs appendChild 单个追加
要渲染一个长列表，该怎么做？是一次性拼接好HTML字符串塞给innerHTML，还是一个一个地用appendChild往里加？从性能角度看，前者通常胜出。虽然innerHTML会触发一次完整的HTML解析和DOM构建，但它通常只引发一次布局重排。反观appendChild，每添加一个元素，尤其是带样式的元素，都可能迫使浏览器重新计算样式和布局，频繁打断渲染流程。
- 面对大量节点插入时，优先考虑字符串拼接或使用
DocumentFragment进行“离屏”组装，最后再一次性挂载到真实DOM中。 - 来看一个典型做法：
const frag = document.createDocumentFragment(); data.forEach(item => { const el = document.createElement('div'); el.textContent = item; frag.appendChild(el); }); container.appendChild(frag); - 需要注意的是，
innerHTML存在XSS安全风险。如果只是处理纯文本，更推荐使用textContent或者做好手动转义。
读取 offsetTop、getBoundingClientRect 触发强制同步布局
这可能是最隐蔽的性能陷阱。当你读取offsetTop、getBoundingClientRect()这类属性时，浏览器为了给你一个精确的、最新的布局值，不得不停下手中的所有工作，立即把队列里所有待处理的样式计算和布局（也就是重排）都给完成了。这个过程被称为“强制同步布局”（Forced Synchronous Layout），它会严重打断浏览器的渲染流水线。
立即学习“前端免费学习笔记（深入）”；
- 切忌在循环中反复读取
el.offsetTop这类布局属性，这等同于在强迫浏览器反复“急刹车”。 - 最佳实践是遵循“读-写分离”原则：先一口气把所有需要读取的布局信息批量读完，缓存起来，再统一进行后续的样式修改或位置计算。
- 同样需要警惕的是，
getComputedStyle(el).height这样的读取，本质上和offsetHeight一样，也会触发同步布局。 - 现代浏览器提供了一些优化选项，例如CSS属性
contain: layout可以隔离元素布局对周围DOM的影响，从而限制重排范围。当然，使用时需要留意其兼容性（Chrome 85+等较新版本）。
说到底，页面卡顿的罪魁祸首，往往不是某个DOM API调用得慢，而是它被用成了“重排触发器”。要定位问题，光看Ja vaScript函数执行时间是远远不够的。打开Chrome开发者工具的Rendering面板，勾选上“Paint flashing”和“Layout Shift Regions”选项，然后在页面上操作一番。瞬间高亮的区域会直观地告诉你，究竟是哪块DOM在偷偷地进行重绘和重排，这远比凭空猜测要靠谱得多。
