如果你是刚接触前端没多久，可能会觉得DOM这个名词很抽象：它明明就摆在浏览器里，能被document.querySelector找到，可真要你说清楚它到底是什么，又说不出来。我当年学DOM也踩过类似的坑——以为HTML源码就是DOM，结果用JS改了页面内容，打开“查看网页源代码”一看，还是老样子，当场就懵了。后来才明白，DOM不是HTML源码，而是浏览器把HTML解析之后生成的一棵“活树”，所有标签都变成了节点，每个节点都可以被JavaScript增删改查。这篇文章我就把DOM彻底拆开讲：从它的真实身份、操作API，到渲染流程、安全风险、虚拟DOM和Diff算法、事件流，顺带提一句测绘领域那个同名缩写DOM，避免你搜资料时被带偏。内容偏干，建议先收藏再往下看。
1. DOM到底是什么：从一张网页到一棵活树的过程
1.1 与HTML的区别：源码是“剧本”，DOM是“现场”
很多人最先接触的概念是HTML，于是想当然地以为DOM就是HTML标签。实际上，两者差别非常大。你在编辑器里写下的HTML文件，本质上只是一段有固定语法的纯文本字符串，浏览器拿到这段文本后要经过读取字节、解析标签、构建结构等多个步骤，才会在内存里生成一个可操作的对象结构，这个结构就是DOM。
你可以把这个过程想象成拍电影：HTML源码是剧本，DOM是在舞台上真正演起来的现场。剧本只要不改写，文字永远不变；但现场却可以被导演实时调整——演员站位变了、灯光变了、台词换了，可剧本依然躺在那里没动过。于是你在DevTools里看到的结构和“查看源代码”看到的不一样，就不奇怪了。
DOM的全称是Document Object Model，中文叫“文档对象模型”。拆开看：Document指网页文档，Object指浏览器把文档中的标签、属性、文本都封装成了对象，Model则说明这些对象之间存在层级关系。所以DOM是浏览器提供的一份编程接口，让JavaScript能够访问和修改网页展示的内容。它不仅是前端面试的高频考点，也是真正理解框架的一把钥匙。
1.2 DOM树长什么样：节点和层级关系
浏览器解析HTML后，会把整个文档构建成树状结构，这棵树就是“DOM树”。树上的每一个分支和叶子，都对应一个“节点”。
其中你最常打交道的有四类节点：
| 节点类型 | nodeType值 | 举例 |
|---|---|---|
| 文档节点（Document） | 9 | 代表整个页面，入口是document |
| 元素节点（Element） | 1 | <div>、<p>、<span>等标签 |
| 文本节点（Text） | 3 | 标签之间的文字内容，包括空格和换行 |
| 注释节点（Comment） | 8 | <!-- 注释内容 --> |
我去年带一个实习生写DOM遍历，他卡了整整一个下午，原因是页面结构明明没错，用childNodes却老是遍历出一些奇怪的东西。后来发现，罪魁祸首正是“文本节点”——HTML里元素之间的换行和空格，都会被当作文本节点挂在树里。所以如果你要纯粹操作元素节点，请优先使用children而不是childNodes，这一点后面讲遍历时会展开。
1.3 为什么浏览器非要弄出DOM这个中间层
HTML是一种标记语言，它只能描述内容长什么样，本身不具备编程能力。而JavaScript是一门脚本语言，它需要一个统一、稳定的接口去访问页面。DOM就是这个接口。没有DOM，JavaScript就是一门“看不见网页”的语言，什么按钮点击、表单校验、动态列表，全都无从谈起。
浏览器的渲染过程，简单来说就是：HTML解析成DOM树，CSS解析成CSSOM树，两棵树合并后生成渲染树，浏览器再把渲染树绘制到页面上。而JavaScript能做的事情，本质上都是对DOM树“这棵内存树”进行读取和修改，修改完之后浏览器重新计算布局并刷新画面。
另外注意一点：DOM标准由W3C等组织制定，浏览器只是按照规范实现了这套接口。这也是为什么主流浏览器都提供document、window这些对象，且API高度一致，前端能一套代码跑遍各个浏览器，DOM规范功不可没。
2. 操作DOM的核心技巧：找节点、读节点、改节点
2.1 查询DOM元素到底用querySelector还是getElementById
日常开发里最常见的第一件事，就是找到页面上的某个元素。最常见的API有两个阵营：
// 传统方式 const a = document.getElementById('app'); const b = document.getElementsByTagName('div'); const c = document.getElementsByClassName('item'); // 现代方式 const d = document.querySelector('#app'); const e = document.querySelectorAll('.item');querySelector和querySelectorAll最大的优点是支持任意CSS选择器，写起来非常直观，比如document.querySelector('ul.list > li.active')，一行就能定位到深层元素。getElementById虽然在性能上略快一点，但正常业务里这点的差距小到可以忽略，我更看重代码可读性。
但这里面有个容易踩坑的细节：getElementsByTagName和getElementByClassName返回的是HTMLCollection，它是“动态集合”。意思是如果后续往页面里新增了同类元素，集合内容会自动更新，甚至在你用for循环遍历的同时新增元素，会出现无限循环的诡异现象。而querySelectorAll返回的是NodeList，通常是“静态快照”，定义时捕获的列表不会自动变化。所以如果你一边遍历一边增删元素，优先用querySelectorAll，否则极易出bug。
2.2 节点之间的父子兄弟关系：小心空白文本节点的埋伏
定位到节点之后，经常需要在DOM树里“爬”：取父节点、子节点、兄弟节点。很多初学者会用parentNode、childNodes、firstChild、nextSibling，结果经常被空白文本节点折磨。
正确且推荐的做法是使用只考虑“元素节点”的API：
const item = document.querySelector('.item'); item.parentElement; // 父元素 item.children; // 所有子元素（HTMLCollection） item.firstElementChild; // 第一个子元素 item.lastElementChild; // 最后一个子元素 item.previousElementSibling; // 前一个兄弟元素 item.nextElementSibling; // 后一个兄弟元素举个例子：你有一份列表，想拿到每一项的序号来完成高亮操作，用item.parentElement找到外层容器，再用Array.from(container.children).indexOf(item)，整个过程不会碰任何空白文本，逻辑非常干净。如果用的是原生children返回的集合，记得用Array.from转成真数组，否则很多数组方法用不了。
2.3 创建与插入：从一个空容器到完整列表
动态创建页面结构是前端的家常便饭。最基础的一套是document.createElement创建元素，再用appendChild或insertBefore把它挂进DOM树：
const ul = document.querySelector('#list'); const li = document.createElement('li'); li.textContent = '新项目'; ul.appendChild(li);这里我要特别分享一个实测经验：如果循环创建大量节点，千万别写一个循环就往页面里appendChild一次。每次插入都会触发浏览器重新执行布局计算，性能非常差。正确做法是先把所有新节点挂到DocumentFragment（文档片段）上，最后一次插进真实DOM：
const fragment = document.createDocumentFragment(); for (let i = 0; i < 1000; i++) { const li = document.createElement('li'); li.textContent = '条目' + i; fragment.appendChild(li); } ul.appendChild(fragment); // 只触发一次页面更新如果只是想在某个位置插入一段HTML字符串，insertAdjacentHTML比innerHTML更安全也更灵活，它有四个位置参数：beforebegin、afterbegin、beforeend、afterend，能精确控制插入点在目标元素的内外前后。
2.4 删除、克隆与替换：别忽略移除后的事件清理
删除节点，老API是parent.removeChild(child)，新API可以直接child.remove()。替换节点则是parent.replaceChild(newChild, oldChild)。克隆节点用node.cloneNode(deep)，参数deep为true时连子节点一起克隆。
这里有一个很多人不会注意到的内存泄漏隐患：用removeChild移除一个绑定了事件监听器的节点后，如果还有外部变量引用着这个节点，它的监听器可能依然存活，造成内存无法释放。在大型单页应用里，反复创建和移除组件，时间久了页面就会越来越卡。稳妥的做法是移除节点前主动解绑事件：el.removeEventListener('click', handler)，或者用AbortController统一控制事件的添加和取消。这块虽然像细节，但线上性能问题十有八九就这样积累出来的。
3. 浏览器如何从上到下构建DOM，以及你该怎么优化渲染
3.1 “DOM从上到下顺序渲染是不是更快”的真相
很多人在学习性能优化时会问：浏览器从上到下边读边构建DOM，那我把代码全写在页面顶部，是不是解析得更快？这句话对了一半。
浏览器的确是从上到下解析HTML，按顺序构建DOM的。但关键在于，DOM的“构建”不等于“渲染”。HTML解析过程中，一旦遇到普通的<script>标签，浏览器会立刻停止DOM构建，先把JS下载并执行完，再继续往下解析。如果脚本放在<head>里且代码逻辑又笨重，用户会一直盯着白屏。这就是为什么老派优化建议都强调“把脚本放到</body>之前”。
同时还有一个容易误解的点：CSS会阻塞渲染，但一般不阻塞DOM构建。浏览器可以一边继续解析HTML生成DOM树，一边等待CSS处理完毕，只是没有CSSOM就拼不出渲染树，也就画不出任何像素。因此典型的优化方案是：把首屏必要的CSS以内联或尽早方式加载，非关键的脚本用defer或async标注，避免插队阻塞。
3.2 DOMContentLoaded和load到底差在哪
判断页面什么时候可以交互，是两个经典事件最常见的用途：
| 事件 | 触发时机 | 适合场景 |
|---|---|---|
DOMContentLoaded | DOM树构建完成，样式表、图片、iframe可能还没加载完 | 绑定事件、初始化业务逻辑，越快越好 |
load | 页面所有资源（图片、样式、脚本等）都已加载完 | 统计页面完整加载耗时、图片尺寸计算 |
实际开发中，如果你在load里才绑定点击事件，用户会觉得按钮反应慢半拍；在DOMContentLoaded之前去查询图片尺寸，往往又会拿不到正确数据。所以性能看板里统计“白屏时间”常用前者，统计“完全加载时间”才用后者。这两个事件是理解页面生命周期最基础的一对。
3.3 回流与重绘：操作DOM最该躲开的性能坑
修改DOM必然带来代价，但代价分两种。重绘（repaint）指样式变化不影响几何布局，比如改颜色、改背景，浏览器只需要重新绘制那一片区域。回流（reflow）则是指元素几何属性发生了变化，比如宽度、高度、位置、字体大小变化，浏览器需要重新计算整棵渲染树的部分甚至全部布局，代价大得多。
为什么说要躲开？因为有些代码会引发“布局抖动”。比如循环里先读element.offsetWidth，再立刻修改element.style.width，浏览器为了保证读取到的值是最新的，不得不提前强制回流一次。读一次回一次流，性能瞬间崩掉。
我自己的习惯是：把读取集中在一起，改写法集中在一起。比如：
// 性能差：循环里读+写交杂 for (let i = 0; i < list.length; i++) { const w = list[i].offsetWidth; list[i].style.width = w + 10 + 'px'; } // 性能好：先批量读数，再批量改写 const widths = []; for (let i = 0; i < list.length; i++) { widths.push(list[i].offsetWidth); } for (let i = 0; i < list.length; i++) { list[i].style.width = widths[i] + 10 + 'px'; }此外，需要频繁变动的元素可以先用display: none把它移出文档流，改完再显示回来，或者用绝对定位把动画效果限定在一个局部区域，减少回流波及范围。也正是因为手动操作真实DOM容易踩这些坑，前端圈才逐渐走向了“虚拟DOM + Diff算法”这套思路，下一节就聊它。
4. DOM安全：一句innerHTML可能让你的网站被攻破
4.1 什么是DOM型XSS：不需要过服务器也能捅娄子
说到安全，就绕不开XSS（跨站脚本攻击）。跨站脚本里有一类叫“DOM型XSS”，它的特点是不必经过服务器处理，攻击代码直接在浏览器的DOM操作过程中被注入和执行。换句话说，就算你的后端过滤做得再严格，只要前端写了危险的DOM拼接，攻击依然可能发生。
常见的数据源头有这么几个：URL哈希（location.hash）、URL查询参数（location.search）、document.referrer、window.name，以及postMessage接收到的消息。这些内容用户可以直接控制，比如在一个搜索页面里，我把参数改成?keyword=<img src=x onerror=alert(1)>，如果前端代码把keyword直接拼进innerHTML，攻击代码就原地执行了。
4.2 最容易写出漏洞的三种代码
我见过很多项目里存在下面这些写法，每一种都是DOM型XSS的“卧底”：
// 危险1：直接把用户输入拼进HTML el.innerHTML = '<div>欢迎你，' + username + '</div>'; // 危险2：用document.write输出外部可控制内容 document.write('<input value="' + location.search.slice(1) + '">'); // 危险3：把不可信内容丢给eval或Function执行 eval(location.hash.slice(1));它们的共同问题，是把“数据”当成了“代码”来解析。用户名本该是普通文本，一旦被拼进HTML，浏览器会把其中的<img onerror>、<script>当成真实标签去执行。防范的核心思路很简单：永远不要把用户可控的内容当作HTML代码来执行。
4.3 防御DOM XSS的实操清单
首先是默认使用textContent而不是innerHTML。只想显示文字时，textContent会将所有内容按纯文本渲染，<img onerror=...>只会原样显示出来，不会执行。
如果确实需要插入HTML，那就要对用户输入做HTML实体转义：
function escapeHTML(str) { return String(str) .replace(/&/g, '&') .replace(/</g, '<') .replace(/>/g, '>') .replace(/"/g, '"') .replace(/'/g, '''); } el.innerHTML = '<div>欢迎你，' + escapeHTML(username) + '</div>';再往上是传输防线，给页面设置内容安全策略（CSP），禁止内联脚本和eval类方法执行。比如在响应头里加上：
Content-Security-Policy: default-src 'self'; script-src 'self'这种情况下，即便攻击者注入了<script>标签，浏览器也会直接拒绝执行。最后是自测：输入一段测试字符串<img src=x onerror=alert(document.cookie)>，如果页面弹出弹窗，说明你的拼接点已经泄漏了。别问我怎么知道的，反正我在本地项目里测出过三次。
5. 虚拟DOM和Diff算法：面试常考但经常讲不清的优化方案
5.1 直接操作真实DOM，慢在哪
前面讲回流和重绘，核心结论是：真实DOM每一次修改都可能触发高昂的布局计算。对于一个复杂页面，我们常常在一段业务逻辑里连续修改多个节点，如果每改一个就立刻反映到浏览器上，代价会被无限放大。
虚拟DOM的思路则是：在JS层面用普通对象模拟一棵DOM树，先在这棵“虚拟树”上完成所有修改，再用Diff算法对比修改前后的两棵虚拟树，找出最小差异集合，最后一次性批量更新真实DOM。类比一下：你有一面墙要重新贴装饰，真实DOM操作相当于每挪一片装饰都要叫装修师傅来一趟；虚拟DOM则是先在图纸上用笔标好所有要动的装饰，最后让师傅一次性施工。省掉了大量中间过程。
5.2 Diff算法到底在比什么
虚拟DOM要高效，关键在Diff算法如何快速找出“哪里变了”。经典的算法做了两条重要假设，让复杂度从理论上的O(n^3)降到接近O(n)：
- 同层对比，不跨层级移动再比较；
- 不同类型的节点直接替换，不去深究内部内容。
实际操作中，Diff会从树的根节点开始，一层一层往下走。如果新旧两个节点类型不同，比如原来是<div>，现在是<span>，直接整个替换。如果类型相同，就对比属性是否变化，然后递归对比子节点。子节点的对比往往离不开key，框架通过key判断哪些子节点是“同一个东西”，从而复用旧节点，而不是把整个子列表删了重建。
没有key或key不唯一时，列表元素哪怕只是顺序调换了一下，框架也可能把所有节点都重新创建一遍，白白浪费性能。更致命的是，如果某个子组件内部有输入框或本地状态，一旦被重建，用户正在输入的内容就丢了。
5.3 面试三连问：快不快、key怎么选、Fiber是什么
第一个高频问题：虚拟DOM一定比直接操作真实DOM快吗？答案是否定的。如果只做一次简单修改，手动textContent = 'hi'比虚拟DOM的全套流程更快。虚拟DOM的价值在于面对复杂、高频、易出错的交互时，把性能下限兜住，同时让开发者不用天天手动优化操作顺序。面试时能说出“虚拟DOM不一定更快，它降低的是心智负担和出错风险，顺便提供批量更新的能力”，会比只背“更快”高级得多。
第二个高频问题：key为什么不能只用index？我建议用一个具体场景回答：一个可拖拽排序的列表，渲染时用数组下标当作key。某次你拖动了列表顺序，框架对比新旧节点时，发现同一个key位置上的元素内容变了，就会直接就地更新，导致组件状态错乱。最典型的翻车场景是列表里有输入框，拖拽后输入框里填的内容跑到了别的行上。正确做法是使用业务数据里稳定且唯一的ID，比如商品编号、用户ID。
第三个问题如果问到Fiber，简单说来是React在16版本后把虚拟DOM的协调过程拆成了可中断的“小任务单元”，让浏览器能在渲染过程中优先响应用户输入，不再一卡到底。这部分不用扯太深，能说清“可调度、可中断、优先级”几个关键词就够了。
6. DOM事件流：捕获、冒泡、委托一次讲透
6.1 一次点击，在DOM树里经历了什么
当你在页面上点击一个按钮，事件并不是简简单单发生在按钮上就结束的。它的完整传播路径要分三个阶段：捕获阶段、目标阶段、冒泡阶段。
你可以把DOM树想象成一栋办公楼，事件是一则消息。消息先由顶楼广播室往下逐层传达，经过一层层走廊直到目标房间，这是捕获阶段；消息到达目标房间，这是目标阶段；随后消息从目标房间再一层层向上汇报，直到回到顶楼广播室，这是冒泡阶段。所以在一个嵌套结构中点击最内层元素时，外层元素的监听器也会收到这次事件，只是时机不同。
完整路径永远是：window->document->html-> ... -> 目标元素 -> ... ->document->window。也就是说，最外层和最内层之间，每个祖先节点都有两次机会处理这个事件：一次在捕获阶段，一次在冒泡阶段。
6.2 addEventListener第三个参数，以及stopPropagation的坑
addEventListener的第三个参数最基础的形式是布尔值：true代表在捕获阶段触发，false或省略代表在冒泡阶段触发。
<div id="outer" style="padding:20px;background:#eee;"> <div id="inner" style="padding:20px;background:#ccc;">点击我</div> </div>const outer = document.getElementById('outer'); const inner = document.getElementById('inner'); outer.addEventListener('click', () => console.log('outer 捕获'), true); outer.addEventListener('click', () => console.log('outer 冒泡'), false); inner.addEventListener('click', () => console.log('inner 目标'), false);点击内层元素，控制台会依次输出：outer 捕获->inner 目标->outer 冒泡。
如果只想让事件停留在某个节点，可以用e.stopPropagation()阻止后续传播。但要注意，如果有多个监听器绑在同一个元素上，stopPropagation并不会阻止同一元素上其他监听器继续执行，想彻底“闭嘴”得用e.stopImmediatePropagation()。此外，针对高频事件（比如滚动、鼠标移动），可以在监听器里加passive: true，告诉浏览器“我不会调用preventDefault，你可以放心滚动”，减少不必要的阻塞。
6.3 事件委托：一个监听器管理一大片元素
事件委托之所以能成立，靠的就是冒泡阶段。当一个事件从最内层元素冒上来，中间所有祖先都能捕获到。于是我只需要在父级挂一个监听器，就能处理所有子元素的事件。
以前需要给100个li各绑一个点击监听，现在只需给ul绑一个：
document.querySelector('#list').addEventListener('click', function (e) { if (e.target.tagName === 'LI') { console.log('你点的是：', e.target.textContent); } });这样做至少有三大好处：节省内存——不用为每个子元素创建独立监听函数；动态生效——后添加进来的子元素无需重新绑定，天然就能响应；代码集中——改动逻辑时只动一处。缺点也很明显：如果监听器挂在document上，页面上任何点击都会经过它，所以必须用e.target做类型判断，避免无关元素触发。同时，像mouseleave这种不冒泡的事件，委托就无能为力了。
6.4 面试口述模板：30秒把事件流讲成亮点
每次面试我都会准备一段流利的“口述稿”，核心思路是把三个知识点串成一条逻辑线：
“DOM事件流分三个阶段。首先是从window到目标节点的捕获阶段，事件一层层向下传播；其次是目标阶段，事件到达实际触发元素；最后是从目标元素向上返回的冒泡阶段。默认情况下，我们用addEventListener监听事件时，第三个参数不传或传false，回调是在冒泡阶段执行的，传true则在捕获阶段执行。事件委托的原理就是利用冒泡：我不用给每个子元素单独绑监听，只在父元素绑定一个监听器，然后通过e.target判断实际点击的是谁。这样既能节省内存，也方便处理动态新增的元素。”
这段话不长，但“三个阶段、默认冒泡、委托原理”三点全踩中了，面试官基本可以确认你是真懂而不是背概念。
7. 别混淆：测绘和前端都叫DOM，但不是同一个东西
7.1 数字正射影像图（Digital Orthophoto Map）是什么
搜“DOM”资料时，经常会有做GIS、测绘的朋友搜到一篇前端博客，反过来也一样。测绘领域里也有个缩写DOM，全称是Digital Orthophoto Map，中文叫“数字正射影像图”。它是由航空或卫星影像经过几何校正、投影变换后生成的平面影像数据，相当于一张消除了地形起伏和相机角度畸变的“真实照片地图”。
你如果同时接触过OSGB，会发现它们经常一起出现。OSGB是倾斜摄影测量里常见的一种三维模型数据格式（OpenSceneGraph Binary），记录的是具有立体结构的建筑物、地形模型；而DOM提供的是二维正射影像底图。在三维GIS平台里，DOM通常被覆盖在地形表面上当“贴图底稿”，OSGB模型则作为立体的构筑物叠在上面，两者一个管平面一个管立体，配合使用能建出既直观又带真实纹理的三维场景。
7.2 如果你在ArcMap 10.8里遇到“DOM切片”该怎么理解
ArcMap 10.8及ArcGIS系列软件里说的“DOM切片”，是把大范围的DOM影像数据按金字塔层级切成很多小块瓦片（Tile），存储到本地缓存或瓦片包中，方便快速浏览和发布。这个操作在测绘内业、GIS数据生产里很常见，本地切片通常关注三个关键点：坐标系是否统一、切片方案是否匹配（比如切片原点、比例尺级别）、像元大小与压缩格式是否合理。
这块我只是简单提一嘴，因为本文主线是前端开发里的DOM。如果你是被“arcmap DOM切片”搜进来的，建议去找GIS教程；如果你是前端读者，以后看到别人讨论DOM时涉及“影像图”“切片”“金字塔”，要知道他们说的不是网页节点。
最后说几句
我自己学DOM的路线大致是：先盘旋在增删改查API里，然后被页面卡顿逼着去深入渲染机制，接着被某个安全演练平台吓出一身冷汗，再把这一切串起来发现，面试题和实际工程经验终于对上了号。调试DOM我有个小习惯：在控制台用console.dir(document.querySelector('.item'))而不是console.log，因为dir会完整展开对象的属性和方法；想快速理解事件流，最好亲自动手写一个嵌套div的demo，再加上stopPropagation跑几遍，比背十篇博客都管用。收藏这篇文章只算第一步，希望你找时间打开浏览器，把这些例子一行行敲出去。把DOM当成熟悉的老朋友之后，再学框架、读源码都会顺手很多。
