我做了几年前端，带过新人、也面试过不少人，发现一个很有意思的现象：很多同学在框架里写了半年组件，Props、状态管理、自定义Hook样样都通，但你冷不丁问一句“JavaScript获取DOM元素的方法有哪些”，他当场就卡住了。倒也不是不会，而是平时都用框架的指令和模板语法，原生DOM交互反而生疏了。但DOM获取元素是前端最底层的功夫——不管是写原生JS、做jQuery插件，还是面试聊事件委托、虚拟DOM，底层都离不开“先拿到那个元素”。这篇文章就把所有常用方法串一遍：各自的返回值、动态还是静态、性能差异、适用场景，以及我这些年踩过的坑。新手可以当系统索引，老手也可以查漏补缺。
1. 先搞懂：DOM到底是什么，我们究竟在“获取”什么
1.1 浏览器眼中的HTML是一棵倒过来的树
很多教程喜欢一上来就罗列方法，但如果不先理解DOM树，后面那些返回值类型（HTMLCollection、NodeList）就很容易混淆。浏览器解析HTML时，会把标签、文本、属性、注释全部转换成一个个节点对象，组成一棵树。树根是document，往下是html、head、body，再往下是各种元素节点。
这棵树里节点分好几类：元素节点（比如div、p）、文本节点（标签中间的文字）、属性节点、注释节点等。而我们日常说的“获取DOM元素”，绝大多数情况下拿的是元素节点。理解这一点很重要，因为Node接口是所有节点的父接口，Element接口才是元素的抽象，很多方法返回的类型不一样，根源就在这里。
1.2 两套接口体系，一个历史遗留
为什么获取一个元素会有十几种方法？归根结底是Web历史演进的结果。早期浏览器厂商各自实现了全套getElementByXXX，后来标准化组织把这些收编进DOM规范；再后来随着CSS选择器越来越强大，W3C又推出了querySelector系列，提供了一套“用CSS语法来找元素”的通用方案。
所以你会看到两套体系并存：一套是getElement系列，按标签名、类名、ID、name属性去匹配，历史悠久、兼容性极好；另一套是querySelector系列，按CSS选择器匹配，灵活、现代、能组合条件。两套都活着，没有谁淘汰谁，只是适用场景不同。
提示：别指望“背一个万能方法走天下”。真正写多了会发现，方法之间不是简单的替代关系，而是互补关系。选择哪一个，取决于你要拿几个元素、拿到的集合是动态还是静态、以及代码要兼容到什么年代。
2. 经典姿势逐个拆：getElementById与getElementsBy系列
2.1 getElementById：ID查找为什么是单数
document.getElementById('app') 是前端最经典的一行代码。它按id属性精确匹配，返回值是一个元素（Element对象），如果没有找到就返回null。为什么是单数？理论上HTML标准要求id在页面内唯一，所以一个就够了。
这里有几个容易被忽略的细节。第一，这个方法严格区分大小写，getElementById('App')和getElementById('app')完全是两码事。第二，如果HTML里id是动态拼接产生的，注意字符串拼接时别传成数字类型，先转成字符串再传。第三，元素还没有渲染到DOM树之前调它会返回null，这个问题我放到第6章重点说。总结起来，getElementById是单元素查找里性能最优、语义最明确的一个，日常用得最频繁。
2.2 getElementsByTagName与getElementsByClassName：注意复数名字和动态集合
这两个都是复数方法，返回的是一个HTMLCollection——一个类数组的实时集合。什么意思？“实时”意味着这个集合是活的，DOM里新增或删除了匹配的标签或类，集合内容会跟着自动变化，拿到的不是快照，而是引用。
getElementsByTagName('div')会返回页面所有div；getElementsByClassName('box')会返回所有带box类的元素。有个容易踩的点：getElementsByClassName支持传多个类名，比如getElementsByClassName('box active')，只有同时具备这两个类的元素才会被选中，且类名顺序无所谓。这和CSS选择器的.box.active是等价语义，但很多初学者第一次看到这个写法会误以为它只认一个类。
2.3 getElementsByName：表单场景里的特殊存在
这个方法的匹配依据是name属性，主要用在表单里。比如一组单选框都有name="gender"，document.getElementsByName('gender')就能一次全拿到。它的返回值是NodeList，不是HTMLCollection，这也是个冷知识。而且应用范围比getElement系列窄很多，一般只在处理表单时才会主动想起它，平时别滥用。
有一点要注意：getElementsByName不仅仅能查到表单控件，任何带name属性的元素都会被命中。所以如果你页面里恰好在普通div上写了name属性，它也会出现在结果里。这个行为符合规范，但第一次遇到的人很容易发懵。
2.4 HTMLCollection和NodeList到底差在哪
很多初学的小伙伴在这里彻底懵了——同样是“复数获取”，为什么返回的类型不一样？我用一个表来说明：
| 返回类型 | 包含内容 | 是否动态 | 常见方法 | 是否支持forEach |
|---|---|---|---|---|
| HTMLCollection | 只有元素节点 | 是 | getElementsByTagName / getElementsByClassName | 现代浏览器基本不支持 |
| NodeList | 可以是任意节点 | 可能是静态，也可能是动态 | querySelectorAll（静态）/ getElementsByName（动态） | 支持（现代浏览器） |
HTMLCollection只有元素节点，所以它身上的属性和方法更“纯”；NodeList可以包含文本节点、注释节点等。动态性方面，getElementsBy系列始终是动态的；querySelectorAll返回的是静态NodeList。至于forEach，HTMLCollection在旧浏览器里不能直接用，需要转成数组，这个问题在第6章细说。
提示：判断一个方法返回的到底是不是“活的”，最简单的实验方法是先获取集合，再往页面插入一个匹配元素，回头用console.log看长度有没有自动变化。实验一遍比背概念记得牢。
3. 现代选择器方案：querySelector和querySelectorAll到底强在哪
3.1 用CSS选择器“降维打击”
document.querySelector('css选择器') 和 document.querySelectorAll('css选择器') 是现代浏览器普及度最高的接口，当年第一次用的时候，让我感觉到“写JS和写CSS终于统一了”。CSS能写的选择器，这两个方法基本都能用：标签选择器、类选择器、ID选择器、属性选择器、伪类、后代选择器、兄弟选择器，甚至可以组合。
比如“页面里data-type=card的div中的第一个p元素”，用getElement系列你得先拿div集合，再循环遍历找p，写一堆代码；用querySelector一行搞定：document.querySelector('div[data-type="card"] p')。这种表达能力就是它最大的价值，选择器的复杂匹配逻辑被浏览器原生处理掉了。
3.2 querySelectorAll返回的是静态NodeList
很多教程只告诉你querySelectorAll返回NodeList，但没强调最关键的一点：它是静态快照。集合在获取那一刻固定下来，之后DOM再变，集合长度也不会变。这点和getElementsBy系列的动态行为恰恰相反。
动态和静态各有什么优劣？动态集合省内存、实时反映页面状态，适合做“筛选器”一类的场景；但很容易在循环里因为长度变化出bug。静态集合拿到的是当时的快照，适合先筛选一次、后面反复使用的场景，行为也更符合直觉。不能说哪一个更好，关键是你得知道当前拿的是哪一种，写逻辑时才能判断它会不会“自己变”。
3.3 三个使用细节：伪类、错误与兼容性
用querySelector有几个注意点。第一，选择器虽然支持伪类，比如:first-child、:nth-child，但像::before、::after这种只能用于渲染的伪元素是选不到的，因为它们不是真实节点，DOM查询自然查不到。第二，选择器写错会直接抛异常（SyntaxError），比如括号不匹配，这一点和getElement系列静默返回null不同——这是好事，写在try/catch里能更早暴露问题。第三，如果要兼容IE8及以下，就得老老实实回到getElementById，这在老项目里依然现实。
3.4 现代项目里我实际怎么用它
在组件化开发里，我已经很少把querySelector用在全局了，更多是拿到一个元素后在其内部继续查找，比如el.querySelector('.item')——这样只搜索el的后代，效率更高、也是合理的封装边界。至于querySelectorAll，在需要“过滤一组元素并批量绑定事件”的场景中非常顺手，因为它支持forEach，可以直接展开处理。
比如有人喜欢在控制台里写一行脚本，document.querySelector('video')拿到视频元素改旋转角度，这就是典型的“元素定位”需求。querySelector最擅长的就是这种需要精确锁定的场景，但注意别为了用它而去全局搜，局部查找时承接的元素必须是确定存在的。
注意：document.querySelector('#id')在语法上完全正确，但既然页面有更专业的getElementById，就没必要绕一圈。工具要选对的，而不是选多的。
4. 不用写方法的快捷通道：body、forms、children与关系导航
4.1 document.body这类固定入口
有些元素根本不需要“获取”，文档对象直接把入口摔在你脸上。document.body就是页面body元素，document.documentElement是html元素，document.head是head元素。写脚本判断页面是否滚动到顶部时，你拿着document.documentElement.scrollTop或者document.body.scrollTop直接读就完事，不需要任何选择器。
还有document.title可以直接读写页面标题，document.URL拿当前地址。这些虽然不完全算“获取元素方法”，但都属于“不查询也能访问”的文档级快捷方式，实际开发里非常常用，值得放在一起记。
4.2 文档级集合属性：forms、images、links、scripts
DOM规范还给document挂了一组快捷集合属性：document.forms是所有表单、document.images是所有图片、document.links是所有带href的a标签、document.scripts是所有script标签。这些集合返回的都是HTMLCollection。它们的价值在于语义化：你想遍历页面上所有表单去做校验时，直接document.forms搭配遍历，比querySelectorAll('form')更直白，代码读起来也更接近业务语义。
我做过一个需求：页面加载完成后自动给所有未填写的input加上红色边框。当时就是document.forms先拿到所有表单，再遍历表单里的elements（注意表单本身也有elements集合属性），整个过程完全没写一个选择器。这种场景下，语义化快捷通道比通用选择器好用得多。
4.3 通过关系导航拿元素：children、parentNode、nextElementSibling
还有一种常见的“获取”，不是通过选择器，而是通过已掌握的元素往周围走：elem.children拿到所有子元素；elem.parentNode拿父节点（注意是Node类型，偶尔需要再判断nodeType）；elem.nextElementSibling拿下一个兄弟元素节点，elem.previousElementSibling拿上一个。这几个在写折叠面板、树形组件时几乎是标配。
这里有个经典细节：children只包含元素节点，childNodes则包含文本、注释节点。很多人写遍历时用了childNodes，结果被空文本节点折磨到怀疑人生——HTML里换行产生的空白字符也是文本节点，childNodes会把它们都列出来。我的建议是：默认操作“元素”时优先用children，除非你真的要处理文本节点。
4.4 老接口的新用法：elem.querySelector和closest
最后补两个容易被忽略的现代API。elem.querySelector(selector)和elem.querySelectorAll(selector)会在“以当前元素为根的子树”里查找，这就实现了局部作用域；elem.closest(selector)则是反着走，从当前元素开始往上找最近一个匹配选择器的祖先元素，找不到返回null。这两者对事件委托场景非常友好，我以前写“点击li找最近的table行”就靠closest，一行解决嵌套层级带来的麻烦。
closest还有一个值得注意的行为：它从当前元素自身开始判断，而不是从父节点开始。也就是说，elem.closest('div')如果elem本身就是div，会直接返回elem。这个细节很多文档没强调，实际写事件委托时恰恰会因此写出更简洁的代码。
5. 实操选型：同一个页面，我按什么标准挑获取方式
5.1 从需求反推：单元素、多元素、动态集合还是静态快照
我先给个最简单的判断框架：要拿一个元素，优先getElementById；要拿多个元素并且希望实时反映页面变化，用getElementsBy系列；要拿多个元素并且只关心当前状态，用querySelectorAll；要通过复杂的组合条件定位，用querySelector；要在已知元素周围导航，用children、parentNode、closest。这个框架不是教条，但能覆盖日常90%的场景。
还有一条隐藏判断标准：你要的是“一批元素”还是“一个元素”。很多人写批量操作时习惯用querySelectorAll，但拿到的是NodeList，虽然支持forEach，但它不是真正的数组，想用map、filter还得Array.from转一下。如果你明确只要一个，querySelector就够，返回的就是Element，不需要再从集合里取[0]。
5.2 一个真实页面场景的拆解
举个例子，一个后台管理页面里有动态渲染的表格，每行一个“删除”按钮，点击后先弹出确认框，确认后删除行。怎么做？我会先给表格容器加一个id，然后事件委托：table.addEventListener('click', (e) => { const btn = e.target.closest('button.delete-btn'); if (!btn) return; ... })。这里我根本没去“全局搜索”按钮，而是靠closest在事件流里定位目标。
如果每行创建时就给按钮绑定click，再配合querySelectorAll('.delete-btn')来批量为已有行绑定，也是常见做法。两种思路对应不同性能模型：前者只绑定一次事件，事件冒泡到table统一处理，适合行数很多的场景；后者绑N次但逻辑更直观，适合行数少、结构稳定的场景。面试里聊事件委托时说的“性能优化”，底层就是这两种模型的取舍。
5.3 性能与兼容性的现实考量
用直觉得出“querySelectorAll比getElementsByClassName慢”这种判断是不可靠的，我实测下来两者量级差异在现代浏览器里几乎可以忽略，真正影响性能的是一个查询的复杂度，尤其是选择器写了很长很长的后代组合时，浏览器要跑匹配算法。更实际的影响是动态集合的生命周期——如果在循环里反复读集合的length，动态集合每次都会重新统计，极端情况效率很低；所以我会在需要连续使用时先把集合转成数组存起来。
兼容性上，偏老的项目优先getElement系列，现代项目以querySelector为主，这算是我的一条经验线。不过这些年我也发现“兼容性”对很多业务来说已经不是首要矛盾了，反而代码的可读性和维护成本更重要。你想想，同事看到document.querySelector('div[data-type="card"] p')和看到三行for循环，哪个更能一眼看出意图？选择器往往是前者。
5.4 我的个人选择习惯
写到这里，我得说一点个人习惯供参考：全局查找用getElementById打头，局部查找用elem.querySelector，批量拿一组相对孤立的元素用querySelectorAll，需要在树里上下级跳转时用关系导航，表单校验优先document.forms。这套组合用了很多年，少踩了不少坑，下面分享几个最常见的坑。
6. 高频踩坑实录：拿不到元素、forEach报错、动态集合死循环
6.1 为什么getElementById总是拿不到元素
这个问题十次有八次是脚本执行时机造成的。script标签放在head里，此时body还没解析，DOM树里根本没有那个id对应的节点，自然返回null。解决办法有三个：把script放到body末尾；使用DOMContentLoaded事件；或者把代码包在defer脚本里。还有一个隐蔽原因：页面里真的有两个相同id的元素（这在动态拼接页面中不罕见），虽然标准说id必须唯一，但浏览器不报错，getElementById只会返回第一个，给调试造成困扰。
排查方法很简单，在控制台里直接输入document.getElementById('你的id')看返回。如果返回null，先确认Elements面板里这个元素确实存在，再确认脚本执行时DOM是否已经加载。这两个确认完，90%的“拿不到”问题都能解决。
6.2 为什么HTMLCollection不能直接用forEach
写惯了数组操作的同学，第一次用document.getElementsByClassName('box').forEach(...) 会直接遇到TypeError。原因我在2.4已经说过了：它不是NodeList，标准设计本身就不包含forEach方法。解决路径有两条：转数组Array.from(collection)后用完整数组方法，或者直接用querySelectorAll从源头拿到支持forEach的NodeList。至于为什么标准偏偏不统一，只能说是历史遗留，习惯就好。
这个坑在面试里经常被反转出来考，面试官会问：“如果HTMLCollection没有forEach，你怎么遍历它？”答案是for循环、Array.from、for...of都可以。而且好消息是，绝大多数现代浏览器的for...of是支持遍历类数组对象的，只要它有length属性和索引下标。
6.3 动态集合引发的“无限循环”
这是我最想提醒的一次事故。假设你要把页面所有div里的空div删除，用getElementsByTagName('div')拿集合后写for循环，每删一个空节点，动态集合的长度就减一，如果循环条件用初始的let i = 0; i < length; i++，根本步进不到真实边界，轻则漏删，重则数组越界。正确做法是倒序遍历，或者先把集合转成静态数组再遍历。这可以说是动态集合最经典的陷阱，面试里聊DOM时也经常被问到。
// 动态集合倒序遍历，避免索引错位 let divs = document.getElementsByTagName('div'); for (let i = divs.length - 1; i >= 0; i--) { if (divs[i].textContent.trim() === '') { divs[i].parentNode.removeChild(divs[i]); } }getElementsByClassName同理。只要记住“动态集合的长度会自己变”，写循环时多留个心眼，这个坑基本就能绕过去。这也是为什么很多风格指南建议“遍历DOM集合前先转成数组”。
6.4 “缓存”的坑：重复查询损耗与集合快照
如果在一个函数里反复document.getElementById同一个id，性能损失很小但显得代码很业余；更关键的是，动态集合保存变量后，变量引用的是实时集合，不是当时的值。我见过有人先let items = document.getElementsByClassName('item'); 然后做了一堆DOM操作，最后以为items还是之前那批元素，结果逻辑全乱。明白动态集合语义后，这类bug基本能一眼识别。
反过来，有人以为querySelectorAll的结果会实时更新，结果操作完DOM再遍历发现还是旧的，这也是对静态快照不理解导致的。两类集合的更新时机恰恰相反，用的时候先问自己一句“我拿到的到底会不会变”，能避免大量莫名其妙的bug。
6.5 别让innerHTML和动态拼接毁掉安全底线
最后补一个和获取元素强相关的安全问题。拿到元素后，很多人习惯直接element.innerHTML = 用户输入，这在某些场景下会引入DOM型XSS。比如你用一个输入框的内容拼到innerHTML里，用户输入一段包含img onerror的字符串，脚本就可能在页面里执行了。正确的做法是优先用textContent，或者用createElement + appendChild去构造节点。我处理动态列表时一直都坚持“宁可多写几行构造节点，也不用innerHTML拼接用户数据”。
// 安全写法：构造节点而不是拼接字符串 const div = document.createElement('div'); div.textContent = userInput; // 纯文本，不会执行任何标签解析 parent.appendChild(div);这还是面试里经常会顺着往下问的点：拿到元素之后，你怎么改内容。如果你每次都是innerHTML一把梭，对面面试官多半会追问一句“如果内容是用户输入呢”。能答出textContent和createElement的区别，这一关才算过。
6.6 顺手送你一个调试技巧
所有获取元素的问题，都可以先打开浏览器控制台，在Elements面板确认目标节点存在、id/class拼写正确，然后在Console里手动输入document.querySelector('#你的选择器')看返回。返回null就检查选择器写法；返回了Element就检查JS执行时机；返回了集合就检查是不是动态集合的问题。三步定位法，比瞎猜快得多。
如果你在调试样式定位问题时想快速试一下选择器，直接在浏览器的Console里输入$$('选择器')（Chrome DevTools的快捷命令，等价于querySelectorAll），可以秒速看到命中元素列表，比反复改代码再刷新快得多。这个技巧我用了很多年，分享给团队后大家都说效率明显提升。
说实话，DOM获取元素的方法不算多，但每个方法背后都藏着一段浏览器演进史：为什么有动态集合，为什么有NodeList，为什么推荐用querySelector又劝你别完全放弃老接口。我个人在实际项目里的体会是，这些方法不要靠背，靠用——写上几十个小交互，你对“什么时候返回HTMLCollection，什么时候返回NodeList”就有肌肉记忆了。最后再提一句，别只盯着获取，拿到元素之后的增删改查同样重要，但那就是另一篇文章了。希望这些经验能帮你少走一点弯路。
