优先用子元素承载数据本身，如复杂内容、含特殊字符、多值、有序场景；属性仅用于标识、开关、技术元数据等修饰性信息。
选属性还是子元素，核心就一条：看它是不是“数据本身”。是数据，就用子元素；是修饰、说明、控制类的附加信息，才考虑属性。
优先用子元素的几种情况
子元素更适合承载真正要交换、展示或处理的内容。
- 内容可能变复杂——比如现在写
<name>张三</name>，以后要拆成姓和名，子元素能直接嵌套：<name><firstname>张</firstname><lastname>三</lastname></name> - 值里带空格、换行或特殊字符——属性值必须引号包裹，还不能直接含
、<code>&等，子元素文本更自由 - 需要多个同类项——比如一个人有多个电话号码，子元素可重复：
<phone>138…</phone><phone>0755…</phone>，属性做不到 - 顺序有意义——比如步骤列表、时间线，子元素天然保序；属性顺序无定义，解析器可任意重排
适合用属性的典型场景
属性不是不能用，而是得用在“配角位”上。
- 纯标识类字段——如
id="1024"、version="2.1"、lang="zh-CN"，不参与业务逻辑，只供程序识别或路由 - 简单开关或状态——如
active="true"、required="yes"，值固定、无扩展需求 - 技术性元数据——如
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"，属于文档结构支撑，和业务数据无关 - 性能敏感的高频访问字段——比如日志条目中的
timestamp，用属性解析更快（但仅在量极大且实测有差异时才值得权衡）
容易踩坑的模糊地带
有些字段看似简单，选错会埋雷。
-
日期——别写
date="2025-12-10"。将来可能要拆年月日、加时区、支持多格式，用子元素<date><year>2025</year><month>12</month></date>更稳 -
地址、描述、备注——哪怕现在只有一行，也别用
address="深圳市南山区..."。这类字段天然易扩展、易国际化，子元素才是正解 -
ID引用——像
refId="user_789"这种关联字段，属性可用；但如果是主键定义（如<id>789</id>），建议仍用子元素，保持语义统一
一个快速自查口诀
能被XPath查出来当内容用的，就该是子元素；只用来过滤、跳转、标记的，才考虑属性。 比如//user[@status='active']查的是属性，//user/status[text()='active']查的是子元素值——前者快但僵硬，后者灵活但稍重。按你的主要使用方式反推即可。
基本上就这些。不复杂，但容易忽略语义分层。
