做数据交换或者配置文件的时候，经常要用到XML。简单的标签嵌套谁都会写，但真碰到层级多、结构复杂的场景，比如订单系统里一个订单带多个商品、每个商品还有不同属性，这时候就得靠XML的复杂结构定义了。
用元素嵌套表达层次关系
XML最自然的方式就是通过嵌套来表现复杂结构。比如你要描述一本书，不只是书名作者，还包含章节、段落、图片引用，就可以一层层往下写。
<book id="101">
<title>深入理解XML</title>
<author>
<name>张三</name>
<email>zhangsan@example.com</email>
</author>
<chapters>
<chapter number="1">
<title>基础语法</title>
<page>10</page>
</chapter>
<chapter number="2">
<title>复杂结构定义</title>
<page>25</page>
</chapter>
</chapters>
</book>属性和元素的合理分工
什么时候用属性，什么时候用子元素？一个实用的经验是：属性放“元信息”，比如ID、状态、版本号；内容性数据用子元素。比如订单的状态可以作为属性，而收货地址这种结构化的信息更适合展开成子元素。
<order status="shipped" order_id="ORD20240801">
<customer>
<name>李四</name>
<address>
<street>花园路88号</street>
<city>杭州市</city>
</address>
</customer>
<items>
<item sku="A001" quantity="2">
<description>无线鼠标</description>
<price>129.00</price>
</item>
<item sku="B205" quantity="1">
<description>机械键盘</description>
<price>499.00</price>
</item>
</items>
</order>复用结构：模板思维很重要
在数据库应用中，XML常用来传输或存储备份结构。如果你发现好几个地方都在写类似的结构，比如“联系人信息”反复出现，那就该考虑统一格式，方便程序解析。别图省事复制粘贴，后期改起来头疼。
比如用户资料和供应商资料都需要联系方式，就可以保持一致的写法：
<contact-info>
<phone type="mobile">13800138000</phone>
<phone type="landline">0571-88889999</phone>
<email>admin@company.com</email>
</contact-info>这样不管是导出报表还是对接API，解析逻辑都能复用。
命名空间避免冲突
当系统变大，不同模块的XML拼在一起时，标签重名是常事。比如财务系统的<order>和仓储系统的<order>可能结构完全不同。这时候就得用命名空间（namespace）来区分。
<finance:order xmlns:finance="http://example.com/finance"
xmlns:warehouse="http://example.com/warehouse">
<finance:amount>999.00</finance:amount>
<warehouse:order order_type="outbound">
<warehouse:item_count>3</warehouse:item_count>
</warehouse:order>
</finance:order>虽然看着复杂了点，但在大型项目里这是避免混乱的关键。
实际工作中，很多人一开始随便写XML，等到要对接系统、导入数据库时才发现结构乱，字段对不上。提前设计好复杂结构，等于给数据打地基，后面省力得多。