getElementById 是浏览器原生最快 DOM 查找方式，因直接哈希查找实现 O(1) 时间复杂度，无需遍历；优于 querySelector 等需解析选择器或扫描节点的方法，但需确保 ID 唯一、合法且元素已存在 DOM 中。
getElementById 是浏览器原生最快的 DOM 查找方式之一，因为它直接利用底层 ID 索引，无需遍历整个文档树。
为什么 getElementById 特别快
现代浏览器为 id 属性维护了哈希表或类似快速查找结构。只要元素有合法的 id（非空、唯一、符合命名规范），调用 getElementById 就是 O(1) 时间复杂度——和元素在页面中的位置、DOM 深度、总节点数完全无关。
对比其他方法：
- querySelector('#myId')：需解析 CSS 选择器、走通用匹配引擎，即使写的是 ID 选择器，仍比 getElementById 多一层开销；
- getElementsByClassName 或 getElementsByTagName：返回实时集合，且需扫描匹配节点，复杂度至少 O(n)；
- querySelectorAll('div#myId')：强制进行完整选择器匹配，性能更差。
使用时的关键前提
性能优势只在满足以下条件时成立：
- ID 在整个文档中唯一（HTML 规范要求，但浏览器不严格校验，重复 ID 会导致 getElementById 返回第一个匹配项，行为不可靠）；
- ID 值不以数字开头（如 id="123" 在部分旧浏览器中可能失败，应避免）；
- 不传入空字符串、null 或未定义值（会返回 null，不报错但逻辑易出错）；
- 确保脚本执行时目标元素已存在于 DOM 中（常见于放在 的脚本，建议延迟到 DOMContentLoaded 后执行，或把 script 放在 body 底部）。
实际优化建议
不必为了“极致性能”而过度重构，但在高频操作或关键路径中值得坚持：
- 优先用 getElementById 替代 querySelector('#xxx')，尤其在循环、动画帧或事件处理器中；
- 对频繁访问的元素，获取一次后缓存到变量，避免重复调用（哪怕它很快，重复查也无必要）；
- 服务端渲染或框架场景下，若 ID 动态生成，确保生成逻辑稳定、不冲突；
- 工具类封装中，可默认优先尝试 getElementById，ID 无效时再退回到 querySelector，兼顾性能与灵活性。
小结
它不是“银弹”，但确实是标准 API 中最轻量、最可预测的元素定位方式。用对了，代码更清晰，运行更稳，还省掉一点隐性开销。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
