17370845950

优先用子元素承载数据本身，如复杂内容、含特殊字符、多值、有序场景；属性仅用于标识、开关、技术元数据等修饰性信息。

选属性还是子元素，核心就一条：看它是不是“数据本身”。是数据，就用子元素；是修饰、说明、控制类的附加信息，才考虑属性。

优先用子元素的几种情况

子元素更适合承载真正要交换、展示或处理的内容。

• 内容可能变复杂——比如现在写张三，以后要拆成姓和名，子元素能直接嵌套：张三
• 值里带空格、换行或特殊字符——属性值必须引号包裹，还不能直接含、&等，子元素文本更自由
• 需要多个同类项——比如一个人有多个电话号码，子元素可重复：138…0755…，属性做不到
• 顺序有意义——比如步骤列表、时间线，子元素天然保序；属性顺序无定义，解析器可任意重排

适合用属性的典型场景

属性不是不能用，而是得用在“配角位”上。

• 纯标识类字段——如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"。将来可能要拆年月日、加时区、支持多格式，用子元素202512更稳
• 地址、描述、备注——哪怕现在只有一行，也别用address="深圳市南山区..."。这类字段天然易扩展、易国际化，子元素才是正解
• ID引用——像refId="user_789"这种关联字段，属性可用；但如果是主键定义（如789），建议仍用子元素，保持语义统一

一个快速自查口诀

能被XPath查出来当内容用的，就该是子元素；只用来过滤、跳转、标记的，才考虑属性。 比如//user[@status='active']查的是属性，//user/status[text()='active']查的是子元素值——前者快但僵硬，后者灵活但稍重。按你的主要使用方式反推即可。

基本上就这些。不复杂，但容易忽略语义分层。