XML（可扩展标记语言）最核心的设计目标之一，就是用一种统一的方式来描述数据之间的层次关系。无论是配置文件、数据交换报文还是文档结构描述，XML都依靠一套严谨的树形模型来表达“谁包含谁、谁和谁平级”的关系。理解这套模型，是掌握XML读写、解析和设计的前提。
一、XML的树形模型：节点是基本单位
一份格式良好的XML文档，在逻辑上就是一棵倒挂的树。树的最顶端有且仅有一个根节点，根节点下面可以挂若干子节点，子节点又可以继续挂自己的子节点，同一父节点下的各个节点互为兄弟节点。这种父子关系和兄弟关系，就是XML表达层次关系的全部基础。
需要注意的一点是，XML要求文档必须有且仅有一个根元素，也就是说所有业务数据都必须被包在这一个根里面。这个规定看似死板，实际上保证了解析器从任何一个入口进入文档，都能沿着唯一的路径遍历整棵树，不会出现“多个源头”导致的歧义。下面是一个最简单的三层结构示例：
<?xml version="1.0" encoding="UTF-8"?>
<!-- 根元素：学校 -->
<school name="第一中学">
<!-- 第二层：年级，school的子节点，三个grade互为兄弟 -->
<grade level="高一">
<class name="1班"/>
<class name="2班"/>
</grade>
<grade level="高二">
<class name="1班"/>
</grade>
</school>上面的例子中，<grade>是<school>的子节点，两个<grade>之间是兄弟关系，而<class>则是<grade>的子节点。层级深度完全由嵌套的层数决定，想表达更深的从属关系，只需要继续往下嵌套即可。这种“嵌套即层级”的直观表达方式，是XML相比CSV这类平面格式最大的优势。
二、属性与子元素：两种表达层级信息的手段
在表达层次关系时，XML提供了两种不同的信息载体：一种是写在开始标签里的属性，比如name="第一中学"；另一种是子元素，也就是嵌套在元素内部的标签。两者都能描述某个节点的特征，但适用场景有明显差异。
属性适合表达那些简单、原子性、不需要再细分的信息。例如一个班级的学生人数，用一个count="45"的属性就足够了。而子元素适合表达复杂的、本身还有内部结构的信息，比如学生的姓名、年龄、各科成绩，这些信息如果全部塞进属性里，标签会变得又长又难读。业界有一条经验法则：元数据用属性，数据内容用子元素。举个对比的例子：
<!-- 方式一：全部用属性，结构扁平但可读性差 -->
<student name="张三" age="16" math="92" english="88" physics="95"/>
<!-- 方式二：用子元素表达，层次清晰，便于扩展 -->
<student>
<name>张三</name>
<age>16</age>
<scores>
<subject name="数学">92</subject>
<subject name="英语">88</subject>
<subject name="物理">95</subject>
</scores>
</student>方式二中，<scores>把成绩组织成一个独立的子树，将来要增加科目、增加学期维度，都可以在这个子树下扩展，而不会影响其他部分。这正是层次化设计带来的可维护性收益。另外要记住，同一个元素的属性不能重名，但子元素可以重复出现，这也是决定“用属性还是用子元素”时的一个硬性判断依据。
三、嵌套规则与常见的设计陷阱
XML的层次关系靠标签的严格配对来维持。每个开始标签必须有对应的结束标签，嵌套必须“后开先闭”，不允许交叉。像<a><b></a></b>这种交叉写法是非法的，解析器会直接报错。这条规则保证了任意一段标签区间要么完全包含另一个节点，要么完全不相交，树形结构因此才成立。
实际设计层次结构时，有几个常见的坑值得警惕。第一是层级过深，有些设计者把所有可能的分类都做成一层节点，结果文档嵌套七八层，既难读也增加了解析成本，一般建议业务层级控制在四层以内，太深的分支可以拆分成独立文档或用属性扁平化。第二是用顺序暗示关系，例如把同级节点排个序就认为它们有先后依赖，这种隐含约定在文档本身中体现不出来，最好用明确的序号属性来表达。第三是忽略了重复节点的定位问题，多个同名兄弟节点并存时，如果没有区分属性（如id），后续处理将很难精确引用其中某一个。
<!-- 反例：层级过深，阅读和维护成本高 -->
<company>
<dept>
<team>
<group>
<member>
<contact>
<phone>13800000000</phone>
</contact>
</member>
</group>
</team>
</dept>
</company>
<!-- 改进：适当扁平化，用属性补充信息 -->
<company>
<member dept="研发部" team="后端组">
<phone>13800000000</phone>
</member>
</company>四、用XPath按层次路径访问节点
层次结构建立起来之后，如何精准定位其中任意一个节点？XPath是XML生态中标准的查询语言，它用斜杠分隔的路径表达式来描述从根到目标节点的完整层级链路，和文件系统路径的思路完全一致。
例如表达式/school/grade/class表示从根元素出发，先找<grade>再找其下的<class>；//class双斜杠则表示在整棵树中任意位置查找，不限定层级。还可以用方括号加条件过滤，比如/school/grade[@level='高一']/class表示只取高一年级下的班级。这种路径式定位之所以可行，底层依据正是XML文档的树形模型：每个节点都有唯一的父节点，路径自然唯一。
<!-- 示例文档 -->
<library>
<category name="编程">
<book id="b001">
<title>XML入门与实践</title>
</book>
</category>
<category name="文学">
<book id="b002">
<title>边城</title>
</book>
</category>
</library>针对上面的文档，/library/category[@name='编程']/book/title会精确返回“XML入门与实践”这个节点，而//book/@id则一次性取出所有图书的id属性。各主流语言都提供了XPath实现，Java的javax.xml.xpath、Python的lxml库等，都允许程序按层级路径直接取值，省去手写递归遍历的麻烦。
五、总结
XML表示层次关系的方式可以概括为一句话：以唯一的根节点为起点，通过标签的严格嵌套构建父子关系，同级元素构成兄弟关系，整份文档形成一棵树。属性适合携带简单的元数据，子元素适合承载有内部结构的数据内容；设计时控制好嵌套深度、给重复节点加上区分标识，再配合XPath的路径表达式进行定位，就能既清晰又高效地表达和访问任意复杂度的层次化数据。掌握这套思路后，无论是阅读别人的XML配置，还是为自己的系统设计数据格式，都会变得有章可循。