属性适用于简单、原子性的元数据如ID和状态，子元素则用于复杂、可扩展或重复的数据结构，优先选择子元素以提升可读性、兼容性和未来扩展性。
在设计XML文档结构时，选择使用属性（attribute）还是子元素（element）是一个常见但容易被忽视的问题。合理的选择能让数据更清晰、易读、可扩展。以下是一些实用的指导原则，帮助你做出合适的设计决策。
1. 用属性表示简单元数据
属性适合存储与元素相关的简单、不可分割的元信息，比如ID、状态、时间戳等。
例如：推荐使用属性的情况：
- 标识符：如 id="123"
- 状态标记：如 status="active"
- 版本或时间：如 version="2.0" created="2025-04-05"
这些值通常是单一的、原子性的，不包含结构。
2. 用子元素表示复杂或可扩展的数据
当数据可能包含多个部分、需要嵌套结构，或未来可能扩展时，应使用子元素。
例如：描述一个人的信息：
不推荐：
<person name="张三" birthdate="1990-01-01" address="北京市朝阳区" />
推荐：
<person>
<name>张三</name>
<birthdate>1990-01-01</birthdate>
<address>
<street>朝阳区某某街</street>
<city>北京</city>
</address>
</person>
子元素更容易扩展，也支持多语言、格式化或附加信息。
3. 属性不支持重复和结构
XML属性的一个硬性限制是：一个元素不能有多个同名属性，且属性值不能包含子结构。
例如，不能这样写：
<book author="张三" author="李四">
这在语法上是错误的。正确做法是使用子元素：
<book> <author>张三</author> <author>李四</author> </book>
如果你的数据可能重复，必须使用子元素。
4. 考虑可读性和工具兼容性
属性看起来更紧凑，但在某些解析场景下不易处理。比如XPath查询、XSLT转换或某些编程语言的DOM操作中，属性和元素的处理方式不同。
子元素在大多数情况下更统一、更直观，尤其在数据驱动的应用中。
如果团队协作或外部系统对接频繁，建议优先使用子元素，减少歧义。
基本上就这些。属性用于轻量级、单一值的元数据；子元素用于内容本身或可能扩展的数据结构。设计时多考虑未来的维护和扩展性，而不是眼前的简洁。
