结论：ID 查询优先用 getElementById，复杂选择器必须用 querySelector；性能差异在于场景适配而非绝对快慢。ID 查找为 O(1) 哈希索引，实测快于 querySelector('#id')；复杂选择器下 querySelector 一次完成且经深度优化，优于组合调用 getElementsBy*。
直接说结论：按 ID 查找时，getElementById 更快更轻量；需要类名、属性、嵌套结构或伪类等复杂逻辑时，querySelector 是唯一且高效的选择。性能差异不是“谁绝对快”，而是“谁更适合当前场景”。
ID 查询场景：优先用 getElementById
ID 在浏览器内部有独立哈希索引，查找是 O(1) 时间复杂度，无需解析、不走 CSS 引擎。实测在 10 万节点 DOM 中，getElementById 平均耗时约 8ms，而 querySelector('#id') 约 25ms —— 后者多出的开销主要来自选择器字符串解析和引擎调用。
- 高频操作（如动画帧内反复获取、事件委托绑定）必须用
getElementById - 语义更清晰：看到
getElementById就知道目标唯一、意图明确 - 不需要引入 CSS 选择器引擎的潜在副作用（如兼容性边界、正则解析异常）
非 ID 查询场景：querySelector 是实际最优解
当你要查 .nav-item[data-active="true"]、form > input[type="email"]:valid 或 #sidebar .list li:nth-child(odd) 时，传统方法必须组合调用（如先 getElementById 再 getElementsByClassName），反而增加代码量和执行步骤。而 querySelector 一次完成，现代浏览器对其 CSS 引擎做了深度优化，尤其在中大型 DOM（>1000 节点）中，它比多次调用 getElementsBy* 快 20%–30%。
- 避免手动遍历和过滤：不用再写
Array.from(getElementsByClassName(...)).find(...) - 支持局部查询：可在任意元素上调用，比如
card.querySelector('.price') - 现代项目中统一使用 querySelector 系列，有利于团队风格收敛和工具链支持（如测试模拟、AST 分析）
别被“平均快慢”误导：看真实调用模式
单纯比单次 querySelector('#id') 和 getElementById('id') 没太大意义。关键看你的典型用法：
- 如果 90% 的查询都是 ID，但混着几个复杂选择器，建议 ID 全部用
getElementById，其余用querySelector—— 不强求统一 - 如果大量重复查询相同选择器（如轮播图频繁找
.slide.active），现代浏览器对querySelector有缓存优化，后续调用会明显加速 -
querySelectorAll和getElementsBy*不可直接对比：前者返回静态 NodeList，后者是动态 HTMLCollection，更新行为不同，影响后续逻辑稳定性
简单决策流程图
遇到一个查询需求，按顺序判断：
- 是不是只靠 ID？→ 是 → 用
getElementById - 是不是要多个结果？→ 是 → 用
querySelectorAll（getElementsBy*返回动态集合，易引发意外交互） - 是不是含类名 / 属性 / 标签 / 伪类 / 嵌套关系？→ 是 → 用
querySelector或querySelectorAll - 是不是在某个子容器里查？→ 是 → 只能用
querySelector（getElementById只作用于整个 document）
