XML文档的数据组织方式看起来很灵活，同一段信息既可以写成元素的文本内容，也可以作为元素的属性出现。比如描述一个人的年龄，可以写成<person><age>25</age></person>，也可以写成<person age="25"/>。两种写法在语法上都合法，解析器都不会报错，但它们在结构表达能力和后续维护上差别不小。理解元素和属性的本质区别，并掌握选择属性的判断标准，是写好XML的第一步。
元素和属性的基本概念
元素是XML文档的骨架，由开始标签、内容和结束标签组成，例如<name>张三</name>就是一个完整元素。元素可以嵌套其他元素，形成树状层级结构，这正是XML表达复杂数据关系的核心能力。属性则依附于元素的开始标签，以名称="值"的形式存在，比如<user id="1001">中的id就是属性。一个元素可以有任意多个属性，但每个属性在该元素内只能出现一次，且属性值必须用引号包裹。
从解析器视角看，两者都会被解析为文档树中的节点：元素成为元素节点，属性成为属性节点。但DOM模型中有个重要细节，属性节点并不属于元素节点的子节点，通过childNodes遍历拿不到属性，只能用getAttribute()方法单独访问。这个特性决定了属性在文档树中处于一种半独立状态，它的存在依赖于所属元素，却不参与元素的层级嵌套。
下面这个例子同时展示了元素和属性的用法：
<bookstore>
<book category="技术" isbn="978-7-111-40701-0">
<title>XML入门教程</title>
<author>李四</author>
<price>59.00</price>
</book>
<book category="文学" isbn="978-7-02-013459-1">
<title>平凡的世界</title>
<author>路遥</author>
<price>68.00</price>
</book>
</bookstore>这个例子中category和isbn是属性，title、author、price是子元素。可以看到，属性适合表达与元素紧密绑定、结构简单的元数据，而需要独立表达、可能扩展的信息则更适合用子元素。
元素与属性的深度对比
扩展性是两者最关键的差异。元素可以随意添加子元素来扩展层级，比如给author加上name、nationality等子标签；而属性值只能是纯文本，无法再嵌套结构。如果某天price需要附带币种和折扣信息，用元素写法可以演变为<price currency="CNY" discount="0.8">47.20</price>或者进一步拆分，而属性写法则要推翻原有设计。对于数据结构可能变化的场景，元素是更安全的选择。
顺序和重复性也有区别。同一元素的多个子元素是有序的，且允许同名重复，比如一本书可以有多个作者，写成多个<author>元素毫无问题；但属性在同一元素内不能重名，也不存在顺序语义。此外，属性值对特殊字符的处理更严格，内容中出现的引号、尖括号都需要转义，处理不当容易引入解析错误。
从解析和查询角度看，主流工具对两者都支持良好，但XPath表达式略有不同：访问元素用/bookstore/book/title，访问属性则用/bookstore/book/@category。在实际开发中，属性访问通常更快一些，因为属性节点数量往往比元素少，文档树更精简，这对大型XML文档的内存占用有一定影响。
何时应该使用属性：实用判断原则
综合W3C的建议和社区实践，属性适合存放以下几类信息：第一类是唯一标识符，如id、isbn，这类值短小、无结构、用于定位元素本身；第二类是与元素强关联的元数据，如version、encoding、category，它们描述的是元素的特性而非业务数据；第三类是默认值或固定值，DTD和Schema中对属性定义默认值的机制比元素方便得多。
反过来说，以下情况应果断使用元素：数据本身是复杂结构或可能包含子结构；同一名称的信息可能重复出现；内容较长或是富文本；未来结构存在变化的可能性。一个简单的自问方法：这个信息是描述对象的元信息，还是对象本身的组成部分？前者用属性，后者用元素。
再看一个综合示例，体会合理搭配的写法：
<order id="A20231215001" status="paid" createdAt="2023-12-15 10:30:00">
<customer>
<name>王五</name>
<phone>13800001111</phone>
<address>
<province>广东省</province>
<city>深圳市</city>
<detail>南山区科技园路1号</detail>
</address>
</customer>
<items>
<item sku="SKU1001" quantity="2">
<productName>机械键盘</productName>
<unitPrice>299.00</unitPrice>
</item>
<item sku="SKU1002" quantity="1">
<productName>无线鼠标</productName>
<unitPrice>129.00</unitPrice>
</item>
</items>
</order>订单的编号、状态、创建时间作为属性简洁明了，客户信息和商品列表则是典型的结构化业务数据，用元素承载。每个item的sku和quantity是短小且不重复的辅助信息，用属性恰到好处。整体文档层次分明，既没有属性爆炸的可读性问题，也没有元素嵌套过深的冗余感。
最后需要提醒的是，一致性比选择本身更重要。团队协作时应约定统一的风格规范，比如标识符一律用属性、业务数据一律用元素，避免同一个文档里两种风格混用。当遇到拿不准的情况，优先选元素几乎不会错，因为元素的表达能力是属性的完整超集，属性能表达的元素都能表达，反之则不然。