XML命名约定是什么 如何规范地命名元素和属性

XML命名须同时满足W3C语法规范与工程可维护性：禁用xml开头、数字/标点开头、空格、冒号（非命名空间场景

）、点号和连字符；推荐小写加下划线，慎用驼峰；属性仅用于元数据，复杂数据用子元素。

XML 元素和属性名不是随便起的——哪怕语法上能通过，不规范的命名会在序列化、反序列化、跨系统解析或 LINQ to XML 查询时埋下硬伤。核心结论是：必须同时满足 W3C 语法底线 + 工程可维护性底线，缺一不可。

哪些字符组合绝对不能用？

这是最容易翻车的第一关。很多开发者试过 first-name 或 user.id，结果在 .NET 的 XmlSerializer 中直接报错，或在 C# 的 XElement 构造时静默失败。

• xml（任何大小写变体，如 XML、Xml、xMl）开头的名称——W3C 明确保留，所有解析器都会拒绝
• 以数字或标点符号开头，例如 1stItem、.config、-hidden
• 含空格： 是非法的，连 XML 编辑器都会标红
• 冒号 : ——除非你明确在定义命名空间前缀（如 xs:schema），否则单独出现在元素名里会触发命名空间解析逻辑，导致意外匹配失败
• 点号 . 和连字符 - 虽然 W3C 允许，但 XmlSerializer 默认不支持映射到 C# 属性（比如 public string first-name { get; set; } 在 C# 里根本不能编译）

推荐的命名方式与实际映射场景

别被“合法即可用”骗了。真正决定你能不能顺利把 XML 和对象双向绑定的，是序列化框架对名称的容忍度。例如 XmlSerializer 要求类成员名必须能一对一映射到元素名，而 System.Text.Json 完全不处理 XML——这点常被忽略。

• 首选小写字母 + 下划线：、 ——兼容所有主流序列化器，也贴近多数数据库字段习惯
• 驼峰式（orderId）仅在明确使用 [XmlElement("orderId")] 显式声明时安全；否则默认会转成 （因 C# 属性名含大写字母，XmlSerializer 默认用 - 分隔）
• 避免非 ASCII 字符（如 ），虽然语法合法，但部分 Java 解析器、旧版 .NET Framework 或 HTTP 传输中 encoding 不一致时会变成乱码或截断
• 属性值永远用引号包裹：，别写成 status=draft——这会让任何 XML 解析器直接判定为格式错误

属性 vs 子元素：一个常被忽视的设计决策

很多人只盯着“怎么起名”，却没想“该不该用属性”。这不是风格问题，而是数据建模问题。

• 属性适合元数据：简单、固定、不可扩展的标识信息，例如
• 子元素适合业务数据：可能含结构、多值、未来要加子字段，例如不要写 ，而应写：

    Beijing
    Chaoyang
  

• 属性无法表达层级、数组或混合内容；一旦你发现想给某个属性再加个“描述”或“时间戳”，就说明它早该是子元素了

最常被忽略的一点：命名空间前缀（如 ns:person）本身不参与校验，但它的 URI 必须全局唯一且稳定。一旦改了命名空间 URI，哪怕元素名完全一样，对大多数强类型反序列化器来说就是另一个类型——这比起名错误更难调试。