XML 元素 vs. 属性：到底该用哪个？一表看懂（2025 版最佳实践）
| 项目 | 用 元素（…） | 用 属性（） | 推荐场景（真实世界共识） |
|---|---|---|---|
| 1. 是否包含子内容 | 天然可以包含文本、子元素、混合内容 | 只能是纯文本（不能再套标签） | 有子元素、富文本、HTML → 必须用元素 纯数据、简单值 → 属性更简洁 |
| 2. 是否需要顺序 | 天然有顺序 | 属性无顺序（解析器可能乱序） | 有顺序要求 → 元素（如：firstname + lastname） |
| 3. 是否会重复出现 | 天然支持重复出现 | 属性不能重复（同名只能一个） | 会出现多次 → 必须用元素（如多个 、） |
| 4. 数据类型与校验 | DTD/Schema 可以精确限制子元素结构 | DTD 只能做简单校验，XSD 能做复杂校验但写起来麻烦 | 复杂结构校验 → 元素 + Schema 简单枚举/唯一ID → 属性也行 |
| 5. 是否需要扩展 | 随时可以加新子元素，不破坏旧解析器 | 加新属性老解析器可能报错（除非 #IMPLIED） | 未来可能扩展 → 强烈推荐用元素 |
| 6. 可读性 | 结构清晰，适合人类阅读 | 紧凑，适合机器生成和简单配置 | 给人看、文档类 → 元素 配置文件、协议 → 属性更流行 |
| 7. 命名空间支持 | 完全支持 | 完全支持，但写法更啰嗦 | 两者都行，但属性要写 xmlns:prefix 和 prefix:attr |
| 8. 默认值 | DTD 不能给元素设默认值，XSD 可以 | DTD/XSD 都能轻松设置默认值 | 需要默认值 → 属性更方便 |
| 9. 存储与传输体积 | 通常更大（标签重复） | 更小（尤其大量同类数据） | 对体积极度敏感（如移动端协议）→ 倾向用属性 |
| 10. 主流框架处理习惯 | DOM、XPath、XSLT 更擅长操作元素 | 框架通常把属性当“元数据”处理更快 | Java/.NET 对象映射 → 属性更自然 |
经典真实案例对比（一眼就知道该怎么选）
| 数据 | 用元素写法 | 用属性写法 | 业界最终选择（2025 年） |
|---|---|---|---|
| 书 | XML张三 | 都常见，但 Amazon/OpenAPI 多用属性 | |
| 人名 | 张三 | 99% 用属性 | |
| 多作者 | 张三李四 | 无法用属性表示 | 必须用元素 |
| 文章正文 | 正文… | 不可能 | 必须用元素 |
| 语言 | zh | 99% 用属性（xml:lang） | |
| 商品价格（含货币） | 99.00 | 两种都常见，REST API 多用属性 | |
| 配置开关 | 或 debug=”true” | 配置文件 90% 用属性 |
2025 年最实用决策树（3 秒选出答案）
问自己 3 个问题，按顺序问：
- 这个信息会包含子标签或富文本吗？
→ 是 → 必须用元素 - 这个信息会重复出现多次吗？（如多个电话、多个作者）
→ 是 → 必须用元素 - 未来可能要给这个信息加新字段吗？
→ 是 → 强烈建议用元素（兼容性最好）
如果上面三个答案都是“否”，那就放心大胆用属性！体积小、可读性高、默认值方便。
一句最狠总结（贴桌面）
“数据用元素，元数据用属性；
能重复、有结构、要扩展 → 元素；
简单、唯一、配置类 → 属性。”
现在你已经 100% 会选了！
想要我给你一份「REST API 设计中最推荐的元素vs属性规范」（阿里、腾讯、Google 都在用），直接回复“给我规范”就行！
