编写可维护XML的核心是清晰性、一致性和可扩展性：使用语义化标签名（如<customerEmail>）、保持层级扁平（≤3层嵌套）、属性表元数据、统一UTF-8编码与小写连字符命名、预留<metadata>等扩展空间并配套XSD校验。
编写可维护的XML文件，核心在于清晰性、一致性和可扩展性。不是堆砌标签，而是让结构本身传递语义，让人和工具都能快速理解、安全修改。
用有意义的标签名，避免泛化或缩写
标签名应准确反映其内容含义，而非技术角色或临时用途。比如用 <customerEmail> 而非 <field2> 或 <cust_em>；用 <orderDate> 而非 <date>（在订单上下文中易歧义）。缩写会增加认知负担，尤其对新协作者或跨团队使用时。
- ✅ 推荐：<billingAddress>、<isSubscribed>、<maxRetries>
- ❌ 避免：<addr>、<sub>、<mr>
保持层级扁平，慎用深层嵌套
超过三层嵌套（如 <a><b><c><d></d></c></b></a>）会显著降低可读性与XPath查询效率。优先考虑属性或同级元素表达简单修饰关系。
- 用属性表达元数据：如 <product id="P1024" status="active">... 比嵌套 <id>P1024</id><status>active</status> 更紧凑且语义明确
- 当子元素逻辑上是并列实体（如多个联系人），用同级 <contact> 而非 <contacts><contact>...</contact></contacts> —— 后者仅在需额外包装元信息（如计数、时间戳）时才必要
统一编码、命名与空格规范
看似琐碎，却是协作底线。所有文件统一使用 UTF-8 编码（声明为 <?xml version="1.0" encoding="UTF-8"?>），标签名全部小写加连字符（first-name），不混用下划线或驼峰；属性值始终用双引号；缩进统一用 2 个空格，不混用 Tab。
- ✅ 正确：<shipping-method type="express">FedEx</shipping-method>
- ❌ 不一致：<ShippingMethod Type='Express'>fedex</ShippingMethod>（大小写混乱、单引号、大小写不一）
预留扩展空间，但不提前过度设计
通过命名留白支持未来字段，例如用 <metadata> 包裹非核心但可能增长的信息（如审计时间、来源系统），而不是把每个潜在字段都预先定义。避免添加空标签（<notes/>）或占位属性（placeholder="true"）——它们只增加噪音，不提供真实约束或价值。
- 需要扩展时，优先新增同级元素（向后兼容），而非修改现有结构
- 若需强校验，配套提供对应 XSD 或 Relax NG Schema，而非仅靠注释说明“此处将来可能有值”
不复杂但容易忽略。好的 XML 不是写一次就扔，而是让人愿意打开、读懂、放心改。
