queryselectorall在低端设备变慢的主因是触发强制同步布局，而非选择器不优雅；只要调用前读取过offsetheight等布局属性，浏览器就会立即执行style+layout计算，导致8–12ms卡顿。
为什么querySelectorAll在低端设备上突然变慢
不是选择器写得不够优雅，而是它触发了强制同步布局。只要你在调用前读过offsetHeight、getBoundingClientRect()或getComputedStyle()，浏览器就会立刻 flush style + layout，把排版工作硬塞进 JS 线程——这在千元安卓平板或旧款 Chromebook 上，一次就能卡住 8–12ms。
- 常见误操作：
document.querySelectorAll('.item')放在滚动监听里，每帧都执行 - 更隐蔽的坑：哪怕只读了一次
el.offsetTop，后续所有querySelectorAll都会被“污染” - 实测数据：200+ 节点的列表中，带布局读取的遍历耗时波动达 4–12ms；纯静态查找稳定在 0.3ms 内
如何避免HTMLCollection的实时性反噬
getElementsByClassName和getElementsByTagName返回的是实时集合（live collection），每次访问.length或[i]都会重新计算匹配结果，等价于反复执行样式重计算。
- 别这么写：
for (let i = 0; i —— <code>els.length每次取值都触发 layout - 正确做法：先转成静态数组，再遍历：
Array.from(els).forEach(...)或[...els].forEach(...) - 如果只是要第一个匹配项，直接用
document.querySelector('.cls')，比getElementsByClassName('cls')[0]少一次集合构建开销
嵌套选择器为何在深 DOM 中代价翻倍
写document.querySelectorAll('.card.active .content .actions button')这种 4 层选择器，浏览器得为每个button向上查 3 层父链。DOM 深度 > 6 时，失败匹配的成本远高于成功匹配。
- 稳的做法分两步：
const card = document.querySelector('.card.active')（O(1) 定位）→card.querySelectorAll('button')（限定范围后路径缩短） - 如果只需一个按钮，用
card.querySelector('button')，比全量查再取[0]省掉 NodeList 构建 - 慎用
parentNode向上爬：每级.parentNode都可能触发 layout，尤其在循环中
递归遍历DOM树时栈溢出与文本节点陷阱
用childNodes递归容易撞上空白文本节点（换行、缩进生成的#text），导致逻辑错乱；而深度超过 100 层的递归，在低端 Android WebView 里极易栈溢出。
- 优先用
element.children代替element.childNodes，它只返回元素节点，干净且快 - 超深 DOM（如动态生成的树形菜单）建议改用栈模拟：
const stack = [root]; while (stack.length) { const el = stack.pop(); /* 处理 */; for (const child of el.children) stack.push(child); } - 遇到 Shadow DOM 必须显式进入：
root.shadowRoot?.querySelectorAll(selector)，否则查不到内部节点
实际项目里最常被忽略的点是：布局读取和 DOM 查找的耦合关系。你以为只是“找几个元素”，但只要前面碰过任何 layout-triggering 属性，后面所有查找就都变成同步阻塞操作——这点在低端设备上会直接暴露为肉眼可见的卡顿。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
