getElementById 比 querySelector 快，因其基于浏览器哈希索引的原生 ID 查找，而 querySelector 需解析选择器并遍历匹配；仅在需复杂选择、动态拼接或复用 css 逻辑时才用 querySelector。
querySelector 和 getElementById 哪个更快？
直接回答：在绝大多数场景下，getElementById 比 querySelector 快，尤其在大型 dom 中差异明显。原因很简单——getElementById 是原生 ID 查找，浏览器内部有哈希索引优化；而 querySelector 需要解析 CSS 选择器、遍历匹配，哪怕只写 #myId，也绕不开选择器引擎开销。
实操建议：
- 只要目标元素有唯一
id，无条件优先用getElementById - 不要为了“写法统一”把
document.getElementById('header')改成document.querySelector('#header') -
querySelector真正该用的场景是：需要复杂选择（如.nav > li:first-child）、动态拼接选择器、或必须复用 CSS 选择器逻辑时
getElementsByClassName 返回的是活节点吗？
是的，getElementsByClassName（以及 getElementsByTagName、getElementsByName）返回的是 htmlCollection，它是**实时（live）集合**——DOM 变动会自动反映在该集合中。这和 querySelectorAll 返回的静态 nodeList 有本质区别。
容易踩的坑：
立即学习“Java免费学习笔记（深入）”；
- 在 for 循环中用
getElementsByClassName删除元素，可能跳过下一个项（因为集合实时收缩，索引错位） - 反复读取
collection.Length可能触发多次重排/重绘（尤其在循环内） - 如果只是查一次、不关心后续更新，用
querySelectorAll('.btn')更可控，且支持foreach
innerHTML vs createElement + appendChild 性能怎么选？
结论很反直觉：小量、简单插入时，createElement + appendChild 更快；大量 HTML 字符串拼接并一次性写入时，innerHTML 更快——但前提是字符串不含用户输入（xss 风险）。
为什么？
-
innerHTML触发浏览器内置 HTML 解析器，对长字符串批量构建 DOM 效率高 -
createElement每次调用都走 js 引擎 → DOM 接口 → 渲染引擎，单次开销大，但可控性强、无注入风险 - 现代浏览器对
innerHTML的优化已非常成熟，但若字符串含变量，模板拼接易出错（比如忘了转义&）
实操建议：
- 插入 1–5 个元素：用
document.createElement+element.appendChild - 插入几十行结构化 HTML（如表格 tbody）：用
innerHTML，但先用DOMPurify.sanitize()过滤 - 永远避免在循环里反复赋值
innerHTML（每次清空重建开销极大）
事件委托该绑定到 document 还是父容器？
绑定到离目标最近的**稳定父容器**，而不是 document 或 body。性能差异主要来自事件冒泡路径长度和监听器触发频率。
为什么？
-
document.addEventListener('click', handler)会让每次点击都执行 handler，再由你手动e.target.matches('.item')判断——无效触发太多 - 如果所有目标都在
#list内，就绑定到document.getElementById('list')，冒泡距离短，且e.target更大概率是目标本身 - 父容器必须存在且不被频繁销毁重建（比如 SPA 中的路由容器就不稳定）
示例：
const list = document.getElementById('product-list'); list.addEventListener('click', e => { if (e.target.classlist.contains('add-to-cart')) { addToCart(e.target.dataset.id); } }); 真实项目里，性能瓶颈往往不在单个 API 选择，而在重复查询、过度绑定、或未节流的高频操作。比如用 querySelector 查同一元素 10 次，比换用 getElementById 但缓存一次更伤。