DOM树遍历慢主因是触发强制同步布局，尤其在低端设备上；应先定位容器再窄范围查找、分两步读写布局信息，并慎用HTMLCollection的实时性。
DOM树遍历慢，不是因为算法复杂度，而是触发了强制同步布局
在低端设备（如千元安卓平板、旧款Chromebook）上，querySelectorAll 或 getElementsByClassName 看似只是“找元素”，但实际执行时可能引发整棵渲染树重算。尤其当遍历前刚读过 offsetHeight、getBoundingClientRect() 或 computedStyle，浏览器会立刻 flush style + layout，把原本异步的排版提前卡在 JS 线程里。
常见误操作：
- 在滚动监听回调中反复调用
document.querySelectorAll('.item')，每次都会从根开始匹配 - 用
for (let i = 0; i 遍历 <code>getElementsByClassName返回的 HTMLCollection —— 它是实时集合，每次取length都触发样式重计算 - 遍历过程中穿插
el.offsetTop，导致每轮都强制 layout
用 parentNode + classList 替代深度选择器匹配
比如你要找所有「当前激活卡片里的按钮」，别写 document.querySelectorAll('.card.active .content .actions button')。这种 4 层嵌套选择器在 DOM 深度 > 6 的页面里，匹配失败成本极高——浏览器得为每个 button 向上查 3 层父链。
更稳的做法是先定位容器，再向下窄范围查找：
立即学习“前端免费学习笔记（深入）”；
- 用
document.querySelector('.card.active')拿到唯一卡片节点（1 次 O(1) 查找） - 在其内部调用
cardEl.querySelectorAll('button')—— 范围限定后，匹配路径大幅缩短 - 如果只需第一个按钮，直接用
cardEl.querySelector('button')，比全量查再取[0]少一次 NodeList 构建开销
实测在 200+ 节点的卡片列表中，后者耗时稳定在 0.3ms 内，前者波动达 4–12ms（低端 Android Chrome）。
避免遍历中读写布局信息，缓存再用
真实项目里最常踩的坑：一边遍历一边算位置，比如给每个列表项加动画偏移。代码看起来干净：
items.forEach(item => {
item.style.transform = `translateY(${item.offsetTop}px)`;
});
但 item.offsetTop 是典型的 layout-triggering 属性，每调用一次就强制刷新一次布局树。100 个 item = 100 次同步 layout，页面直接卡死。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
正确做法分两步：
- 第一遍只读：收集所有需要的 layout 数据（
offsetTop、clientWidth等），存在数组或 Map 里 - 第二遍只写：用缓存好的数值批量设置
style或 class
额外提醒：getBoundingClientRect() 比 offsetTop 更重，它要算整个盒模型；若只需垂直位置，优先用 offsetTop + offsetParent.offsetTop 手动累加。
HTMLCollection 不是数组，别把它当真
getElementsByClassName 和 getElementsByTagName 返回的是 HTMLCollection，不是 Array。它没有 map、filter，而且最关键的是——它是实时的。
这意味着：
- 你在 for 循环里写
for (let i = 0; i ，每次判断条件都要重新计算 <code>length，触发样式重算 - 循环中途插入新节点，
els.length立刻变大，可能造成无限循环 - 哪怕你只读不写，只要 DOM 树有变动（比如其他脚本 appendChild），这个集合就动态更新
解决方法很简单：转成真数组或静态 NodeList。
- 转数组：
Array.from(els)或[...els]（ES2015+） - 转静态 NodeList：
document.querySelectorAll('.cls')—— 它不响应后续 DOM 变更，且length是固定值
注意：querySelectorAll 虽然也慢，但它至少不会因 DOM 变动而“活”起来；而 HTMLCollection 的“活”是性能隐形杀手。
DOM 遍历本身不慢，慢的是你没意识到每次属性读取都在和浏览器的渲染流水线抢资源。真正关键的优化点，永远不在“怎么更快地遍历”，而在“怎么让遍历不触发 layout”。
