绝大多数现代场景优先用 querySelector() 或 querySelectorAll()；ID 唯一时 getElementById() 最快且稳定；getElementsBy* 返回实时 htmlCollection 易出错；需确保 dom 就绪再查询。
document.querySelector() 和 document.querySelectorAll() 怎么选
绝大多数现代场景下，优先用 document.querySelector()（单个元素）或 document.querySelectorAll()（nodeList 集合）。它们支持完整的 css 选择器语法，比如 .nav-item[data-active="true"]、section > h2:first-child，写法直观且兼容性好（IE8+）。
注意：返回空结果时，querySelector() 返回 NULL，而 querySelectorAll() 返回空的 NodeList（不是数组，但可用 [...nodeList] 展开或 Array.from() 转换）。
- 想取第一个匹配项 → 用
querySelector() - 要遍历所有匹配项 → 用
querySelectorAll()，别用getElementsBy*系列再转数组 - 动态更新的 DOM（如 vue/react 渲染后）→ 这两个方法每次调用都重新查询，更可靠
getElementById() 还值得用吗
值得，而且是最快的选择。只要 ID 是合法且唯一的（HTML 标准要求 ID 全局唯一），document.getElementById("header") 比任何 CSS 选择器都快，不走样式匹配引擎，直接哈希查找。
常见误用：getElementById() 参数不能带 #，写成 getElementById("#header") 会返回 null —— 这是新手高频错误。
立即学习“Java免费学习笔记（深入）”；
- ID 中含特殊字符（如
user-name-1）？可以，但需确保 HTML 中真实存在，且 js 中不加# - 服务端渲染 + 客户端 hydrate 场景下，它比 querySelector 更稳定（不受 class 名动态拼接影响）
- 不支持伪类或属性选择，纯 ID 匹配，功能单一但精准
getElementsByClassName() 和 getElementsByTagName() 的坑在哪
它们返回的是 HTMLCollection，不是数组，是「实时集合」（live collection）：DOM 变动会自动反映在该集合中。这容易引发意料外的行为。
例如：循环中用 getElementsByClassName("item").Length 控制次数，同时又在循环里删元素 → 集合长度实时缩短，导致漏处理。
- 要安全遍历？先转成静态数组：
Array.from(document.getElementsByClassName("item")) - 性能敏感场景（如动画帧内）避免反复调用，缓存结果；
querySelectorAll()返回静态 NodeList，更适合这类用途 -
getElementsByTagName("*")看似方便，但全量遍历开销大，chrome 中比querySelectorAll("*")还慢
为什么 document.querySelector(“input[type=checkbox]”) 有时拿不到元素
最常见原因是执行时机不对 —— 脚本在 DOM 加载完成前就运行了。比如 script 放在 里，没加 defer 或事件监听。
另一个隐蔽原因：表单控件（如 ）若被 JS 动态插入，或由框架（React/Vue）控制渲染，原生选择器可能查不到「初始 HTML 中不存在」的节点。
- 确保 DOM 就绪：
document.addEventListener("DOMContentLoaded", () => { /* 查询 */ }) - 异步内容（如 ajax 加载、组件挂载后）→ 不要靠定时器轮询，改用 MutationObserver 或框架提供的生命周期钩子
- Shadow DOM 内部元素？普通
querySelector查不到，得用shadowRoot.querySelector()
实际项目里，querySelector 和 getElementById 覆盖 95% 的需求；其余方法只在特定约束下才需要，比如维护老代码或做性能极致优化。别为了“多学几个 API”而刻意替换。