文档对象模型(Document Object Model，缩写 DOM)是一套与平台和编程语言无关的应用程序编程接口，用于表示和操作 HTML 与 XML 文档。它把文档抽象为由节点构成的树状结构，程序可以通过标准接口读取、修改、增加或删除文档的内容、结构与样式。该规范由万维网联盟(W3C)推动制定，1998 年 10 月 1 日 DOM Level 1 成为 W3C 推荐标准；此后标准的维护工作逐步转移到网页超文本应用技术工作组(WHATWG)，以持续更新的活标准形式发布。
定义
文档对象模型是一套平台中立、语言中立的应用程序编程接口，用来表示和处理 HTML 与 XML 文档。按 W3C 规范的说法，它提供了一组标准对象来表示文档、一套标准的对象组合方式，以及一套访问和操作这些对象的标准接口，因此开发者可以针对统一接口编写程序，而不必迁就各家产品私有的接口，从而提升网页之间的互操作性[1]。
DOM 是规范层面的接口约定，而不是某一套具体的数据结构。规范明确说明它所定义的是接口与语义，不规定实现方式，也不定义二进制兼容性；只要支持规范中的接口，实现者可以用任何方便的内部表示来保存文档[2]。名称中的“对象模型”取自面向对象设计的传统含义：文档及其组成部分被建模为具有行为和标识的对象，模型既涵盖文档结构，也涵盖其行为[3]。
原理
DOM 把文档呈现为由节点构成的层级结构。文档在逻辑上呈树形，更准确地说像一片“森林”，因为一个文档中可能存在多棵树；每个文档包含 0 或 1 个文档类型节点、1 个根元素节点，以及 0 个或多个注释、处理指令[3]。节点分为若干类型，例如 Document、DocumentFragment、DocumentType、Element、Attr、Text、Comment、CDATASection、ProcessingInstruction 等，其中一些类型可以带有特定类型的子节点，另一些则是不能有下级的叶节点[2]。
规范用结构模型这一术语描述文档的树状表示。结构模型具有“结构同构”的性质：只要依据同一份 XML 信息集，任意两个符合规范的实现为同一文档建立的表示应当具有相同的结构模型；不过解析器行为可能带来差异，例如解析器丢弃空白字符时，DOM 中就不会保留元素内容里的空白[3]。
访问方式上，DOM 用一对读写函数表达属性：在语言绑定中，IDL 里定义的属性被翻译成 get()/set() 函数而非数据成员，只读属性则只有 get() 函数；用户一般通过 Document 类上的 createX() 方法创建文档结构，由实现在这些方法中生成自身的内部表示[2]。除 Java 与 ECMAScript 之外的语言绑定可以由实现者自行选择，以贴合各自的运行环境[2]。
发展历程
DOM 的直接前身是动态 HTML。当时的网页脚本和 Java 程序要在不同浏览器之间通用，却缺乏统一的接口，DOM 正是为解决这一问题而提出的规范，其早期设想也主要围绕浏览器展开[3]。1997 年 10 月 9 日，W3C 发布了 DOM 规范 Core Level 1 的首个公开工作草案，参与 DOM 工作组的厂商包括 ArborText、Grif、IBM、Inso、微软、网景、Novell、对象管理组织、SoftQuad 与太阳微系统等[4]。
1998 年 10 月 1 日，DOM Level 1 成为 W3C 推荐标准，被描述为跨行业就“通过 Java 或 ECMAScript 等编程语言操作文档与数据”达成的标准接口共识[5]。这一级的规范分为核心与 HTML 两部分：核心部分提供能表示任意结构化文档的基础接口，并定义了表示 XML 文档的扩展接口；只处理 HTML 文档的实现不必实现这些 XML 扩展接口，但所有核心基础接口都必须实现[1]。
DOM Level 2 于 2000 年 11 月 13 日成为 W3C 推荐标准，它在 Level 1 核心的基础上扩充出操作文档结构与内容的接口，并在规范中引入 getElementById 函数、事件模型，以及对 XML 命名空间与 CSS 的支持[6][7]。2004 年 4 月发布的 DOM Level 3 进一步加入对 XPath 与键盘事件处理的支持，并提供了把文档序列化为 XML 的接口[7]。
W3C 的 DOM 工作组在 2004 年发布最终推荐标准后解散，标准的后续开发转移到 WHATWG，并以其活标准的形式持续维护；W3C 则改为发布该活标准的稳定快照，2015 年 11 月发布的 DOM Level 4 即为这样的快照[7]。2015 年 4 月 28 日的 DOM4 最后征求意见工作草案同样说明，它是以 WHATWG 活标准为蓝本发布的快照，并尽可能把两者差异限制在删除尚未实现内容的范围内[8]。
应用
浏览器把下载到的 HTML 解析为 DOM，再依据 DOM 中的对象渲染页面。以支持 HTML5 的浏览器为例，DOM 按 HTML5 的要求生成，浏览器再依相应规则把 DOM 对象翻译为可视表示；网页中与视频、输入框、脚本等对应的 DOM 对象，其可控属性会随状态变化而改变网页呈现[9]。
DOM 也是动态更新网页的基础。有了它，程序可以构建文档、遍历结构、添加、修改或删除元素与内容，HTML 或 XML 文档中的内容原则上都能通过该接口访问、修改、删除或添加。由于脚本无需为每次改动请求服务器，页面可以在浏览器内就地更新；同样的结构也便于检查与调试 HTML 与 CSS[10]。
DOM 的适用范围不限于网页。XML 常被用来表示存储于不同系统中的各类信息，其中许多内容传统上被视为数据而非文档；DOM 可以用于管理这类数据，而不只是管理 HTML 页面[11]。在浏览器之外，其他编程语言也可以提供 DOM 实现，用于在页面之间迁移信息或从页面中提取内容[10]。
局限
DOM 并不定义文档中哪些信息是相关的，也不规定信息如何组织，这部分内容对 XML 而言由 W3C 的 XML 信息集规定，DOM 只是面向该信息集的一套接口[3]。它也不是把对象持久化为 XML 或 HTML 的手段：规范说明的不是对象如何用 XML 表达，而是 XML 和 HTML 文档如何被表示为对象，以便在面向对象的程序中使用[3]。
在大型文档上，把整份文档载入内存的表示方式存在明显开销。有研究指出，标准的内存表示方法在处理大型 XML 文档时，无论在占用空间还是由此带来的时间开销上都相当不足，很容易出现文档无法完整载入主存的情况，该研究因此提出以虚拟内存技术按需换入换出内存块来缓解这一问题[12]。DOM 规范本身也未规定多线程机制[2]。
规范还包含若干自我限定。DOM 不是二进制规范，同一语言绑定写成的程序可在不同平台间保持源码兼容，但规范不定义任何形式的二进制互操作；DOM 也不是一组数据结构，而是规定接口的对象模型，规范中的父子关系图表达的是编程接口定义的逻辑关系，并非某种具体内部数据结构[3]。此外，规范强烈不建议厂商加入私有扩展，要求作者不要使用这类扩展，因为会降低互操作性、使用户群体割裂[13]。
标准治理层面也曾出现分歧。围绕 DOM 4.1 规范，苹果、谷歌、微软与 Mozilla 等浏览器厂商曾提出反对意见，认为该规范与 WHATWG 的 DOM 活标准存在不兼容之处，这一分歧影响了规范的推进[14]。
参见
参考资料
- w3.org 上的网页 [引用日期2026-10-14]
- The Document Object Model is not a binary specification [引用日期2026-10-14]
- What is the Document Object Model? [引用日期2026-10-14]
- w3.org 上的网页 [引用日期2026-10-14]
- w3.org 上的网页 [引用日期2026-10-14]
- Document Object Model (DOM) Level 2 Core Specification [引用日期2026-10-14]
- Document Object Model [引用日期2026-10-14]
- RfC: Last Call Working Draft of DOM4; review deadline May 19 [引用日期2026-10-14]
- US20140181947 [引用日期2026-10-14]
- CS316: Web Programming [引用日期2026-10-14]
- ::: TTA표준화 위원회 ::: [引用日期2026-10-14]
- DEXA.2008 [引用日期2026-10-14]
- W3C DOM4 [引用日期2026-10-14]
- W3C 强推 DOM 4.1 ，谷歌苹果微软Mozilla 齐反对 [引用日期2026-10-14]