频繁调用 document.getElementById 会拖慢脚本执行，因其每次触发整棵 DOM 树遍历与匹配；建议缓存引用，避免在高频回调中重复查询。
频繁操作 document.getElementById 会拖慢脚本执行吗
会，但不是因为 DOM 本身“重”，而是每次调用都触发一次树遍历 + 元素匹配。如果在循环里反复写 document.getElementById('btn')，等于反复搜索整个 DOM 树，尤其在深层嵌套或节点量大时（比如上万节点的表格页），性能损耗明显。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 把常用元素缓存到变量里，比如
const btn = document.getElementById('btn');，后续直接用btn - 避免在高频回调（如
scroll、mousemove）中现场查 DOM，提前取好引用再绑定 - 注意缓存时机：如果元素可能被移除或替换（如 SPA 路由切换），要重新获取，不能无脑复用旧引用
innerHTML 批量插入比循环 appendChild 快多少
快不少，但代价是 HTML 字符串拼接易出错、无法复用已有节点、且会销毁子节点绑定的事件监听器。浏览器对 innerHTML 的解析和批量渲染做了优化，而连续调用 appendChild 会多次触发样式计算和布局重排（reflow）。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 插入纯静态内容（如列表项文本）且数量 > 50 条时，优先用
innerHTML拼接字符串后一次性写入 - 需要保留事件监听、或插入含表单控件/第三方组件的节点时，改用
DocumentFragment+appendChild组合，避免 layout thrashing - 不要用
innerHTML += 'xxx'—— 这会强制读取当前 HTML 再拼接再全量重写，等价于反复 DOM 解析
为什么 getBoundingClientRect() 在循环里调用特别卡
因为它强制触发同步布局计算（layout flush）。只要 DOM 结构或样式有未应用的变更（比如刚改了 style.width），浏览器就得立刻回溯计算位置尺寸，打断渲染流水线，造成严重阻塞。
常见错误现象：for 循环里一边改元素 top，一边立即调 getBoundingClientRect()，结果帧率暴跌。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 把所有样式修改集中做完，再统一读取一次
getBoundingClientRect() - 用
requestAnimationFrame分离读写操作：写样式放一帧，读尺寸放下一帧 - 能用 CSS
transform替代top/left位移的，优先用前者 —— 它不触发 layout，只走合成层
querySelectorAll 返回的是实时集合吗
不是。它返回的是一个静态 NodeList，快照式结果，后续 DOM 变更不影响已获取的列表。这点和 getElementsByClassName 返回的动态 HTMLCollection 完全不同 —— 后者每次访问 .length 或索引都会重新查 DOM。
容易踩的坑：
- 误以为
querySelectorAll会自动更新，结果删掉几个元素后还按原长度遍历，导致undefined报错 - 在长列表渲染中混用
getElementsByClassName和querySelectorAll，前者性能更差但语义看似更“直观” - 用
forEach遍历querySelectorAll结果没问题，但别试图对它调.map（老版本 IE 不支持）
offsetHeight，多走一趟 getComputedStyle，或者没意识到 style.color = 'red' 和 style.setProperty('color', 'red') 在触发重排上的细微差别。这些细节不报错，但会在用户滑动页面时悄悄吃掉帧率。 
