XML命名须同时满足W3C语法规范与工程可维护性：禁用xml开头、数字/标点开头、空格、冒号（非命名空间场景）、点号和连字符；推荐小写加下划线，慎用驼峰；属性仅用于元数据，复杂数据用子元素。
XML 元素和属性名不是随便起的——哪怕语法上能通过，不规范的命名会在序列化、反序列化、跨系统解析或 LINQ to XML 查询时埋下硬伤。核心结论是：必须同时满足 W3C 语法底线 + 工程可维护性底线，缺一不可。
哪些字符组合绝对不能用？
这是最容易翻车的第一关。很多开发者试过 first-name 或 user.id，结果在 .NET 的 XmlSerializer 中直接报错，或在 C# 的 XElement 构造时静默失败。
-
xml（任何大小写变体，如XML、Xml、xMl）开头的名称——W3C 明确保留，所有解析器都会拒绝 - 以数字或标点符号开头，例如
1stItem、.config、-hidden - 含空格：
- 冒号
:——除非你明确在定义命名空间前缀（如xs:schema），否则单独出现在元素名里会触发命名空间解析逻辑，导致意外匹配失败 - 点号
.和连字符-虽然 W3C 允许，但XmlSerializer默认不支持映射到 C# 属性（比如public string first-name { get; set; }在 C# 里根本不能编译）
推荐的命名方式与实际映射场景
别被“合法即可用”骗了。真正决定你能不能顺利把 XML 和对象双向绑定的，是序列化框架对名称的容忍度。例如 XmlSerializer 要求类成员名必须能一对一映射到元素名，而 System.Text.Json 完全不处理 XML——这点常被忽略。
- 首选小写字母 + 下划线：
- 驼峰式（
orderId）仅在明确使用[XmlElement("orderId")]显式声明时安全；否则默认会转成XmlSerializer默认用 - 分隔） - 避免非 ASCII 字符（如
），虽然语法合法，但部分 Java 解析器、旧版 .NET Framework 或 HTTP 传输中 encoding 不一致时会变成乱码或截断 - 属性值永远用引号包裹：
status=draft——这会让任何 XML 解析器直接判定为格式错误
属性 vs 子元素：一个常被忽视的设计决策
很多人只盯着“怎么起名”，却没想“该不该用属性”。这不是风格问题，而是数据建模问题。
- 属性适合元数据：简单、固定、不可扩展的标识信息，例如
- 子元素适合业务数据：可能含结构、多值、未来要加子字段，例如不要写
，而应写：Beijing Chaoyang - 属性无法表达层级、数组或混合内容；一旦你发现想给某个属性再加个“描述”或“时间戳”，就说明它早该是子元素了
最常被忽略的一点：命名空间前缀（如 ns:person）本身不参与校验，但它的 URI 必须全局唯一且稳定。一旦改了命名空间 URI，哪怕元素名完全一样，对大多数强类型反序列化器来说就是另一个类型——这比起名错误更难调试。
