明明是“父子关系”，为何要“分家”？——重新审视 DOM 与 BOM 的设计哲学
前言
作为前端开发者，document和window是我们最熟悉的两个老朋友。但我们在构建知识体系时，常常会忽略它们背后有趣的设计逻辑。
最近在复盘前端基础架构时，我重新思考了一个看似简单却耐人寻味的问题：
从代码运行层面看，DOM（Document）明明是 BOM（Window）的一个子属性，属于包含关系。但在标准规范和实际开发中，我们为什么总是习惯把它们看作两个独立的、平行的核心概念？
这不仅仅是一个分类问题，更折射出了浏览器架构演进的一段历史。今天想从标准演进与设计哲学的角度，聊聊我的理解。
1. 物理视角：它们确实是“一家人”
首先，我们需要还原“案发现场”。在浏览器的运行时（Runtime）环境里，它们的关系是非常明确的上下级关系。
BOM（浏览器对象模型）的核心是window，它代表了整个浏览器窗口这个容器。而DOM（文档对象模型）的核心document，老老实实地挂在window下面。
JavaScript
// 事实胜于雄辩：Document 确实寄人篱下 console.log(window.document === document); // true这就好比：Window 是房子，Document 是挂在房子墙上的一幅画。从物理空间上说，画当然属于房子的一部分。
我们可以用一张简单的层级图来表示这种运行时结构：
Code snippet
2. 逻辑视角：为何必须“解耦”？
既然物理上是包含关系，为什么在工程概念里，我们非要强调它们的独立性？这其实是标准制定者有意为之的“解耦”。
我们可以把这看作是“通用法律”与“地方方言”的区别。
2.1 DOM 是“通用法律” (The Standard)
DOM 的标准是由W3C制定的。它的野心很大，不仅仅是为 JS 服务，它是为所有编程语言设计的文档操作接口。
Python 解析 XML 用的是 DOM。
Java 解析 HTML 用的也是 DOM。
它的设计初衷是跨平台、跨语言的。
为了保证这份“法律”的通用性，它必须保持纯洁，不能和具体的“浏览器环境”绑定太死。
2.2 BOM 是“环境方言” (The Environment)
BOM 在很长一段时间里，属于各个浏览器厂商（Netscape, IE）为了控制自家浏览器行为（如弹窗、跳转、历史记录）而搞出来的接口。
它更像是**宿主环境（Host Environment）**提供的能力。
我们可以通过下图清晰地看到这种标准来源与使用场景的分离：
Code snippet
思考：
如果我们把 DOM 和 BOM 强行捆绑在一起，那就意味着以后我在 Node.js 或者 Python 里操作 XML 时，还得被迫引入一个莫名其妙的 window 对象，这显然是不合理的。
所以，将 DOM 从逻辑上剥离出来，是为了让核心业务逻辑（文档操作）具有更强的生命力和移植性。
3. 工程视角：为什么我们更关注 DOM？
在日常开发中，我们对 DOM 的关注度往往远高于 BOM，这并非厚此薄彼，而是由业务价值决定的。
BOM 是“壳”：它负责环境交互（如获取屏幕宽度、读取 URL 参数）。随着现代框架（Vue/React）的成熟，很多 BOM 的底层差异已经被框架抹平了。
DOM 是“核”：前端开发的本质是 GUI 编程。用户看到的界面结构、样式渲染、交互反馈，90% 都是在与 DOM 打交道。
我们在做架构设计时，通常也会遵循这种思想：把业务核心数据（DOM）与环境依赖（BOM）分离开来，这样代码才更健壮。
4. 总结
通过这次梳理，我们可以得出一个更清晰的前端体系视图，正如“三架马车”各司其职：
Code snippet
理解了这种**“物理包含，逻辑解耦”**的设计哲学，我们在写代码时，就能更清晰地界定什么时候该找“房子”（Window），什么时候该改“画”（Document）。