.NET的System.Xml.Linq命名空间详解

XDocument 是轻量、不可变、支持 LINQ 的 XML 模型，比 XmlDocument 更简洁安全；需注意路径解析依赖当前工作目录、保存默认 UTF-16 带 BOM、XAttribute 对 null 静默转空字符串、Descendants() 性能差及 XNode 类型混淆问题。

XDocument 是 System.Xml.Linq 的核心，它不是对 XmlDocument 的简单包装，而是基于函数式编程思想重新设计的轻量、不可变（操作后返回新对象）、支持 LINQ 查询的 XML 模型。如果你还在用 XmlDocument.Load() 做配置读取或生成简单 XML，XDocument 几乎总是更简洁、更安全的选择。

加载和保存 XML 时路径与编码容易出错

使用 XDocument.Load() 时，如果传入的是相对路径，会按当前工作目录（Environment.CurrentDirectory）解析，而非程序集所在目录——这在 Windows 服务、IIS 或 dotnet test 中极易导致 FileNotFoundException。保存时若未显式指定 Encoding.UTF8，默认用 UTF-16（带 BOM），某些下游系统（如旧版 Java WebService）可能拒绝解析。

• 用 Assembly.GetExecutingAssembly().Location + Path.GetDirectoryName() 构造绝对路径
• 保存时显式用 doc.Save(new StreamWriter(path, false, Encoding.UTF8))
• 避免直接传字符串路径给 XDocument.Load(string)，优先用 Stream 或 TextReader，便于 Mock 和编码控制

XElement 与 XAttribute 的构造逻辑不一致

XElement 构造时传入 null 会抛 ArgumentNullException；但 XAttribute 构造时传入 null 值，会静默转为空字符串（""），不是 null 也不是缺失属性——这会导致序列化后 XML 出现意外的空属性，比如 id=""。

XElement el = new XElement("item", new XAttribute("id", null)); // 实际生成 id=""

• 写入前用 string.IsNullOrEmpty(value) 判断，决定是否创建 XAttribute
• 读取时别依赖 attr.Value == null 判定属性是否存在，应先用 el.Attribute("id") 检查是否为 null
• XElement.SetAttributeValue("id", value) 会自动处理 null：值为 null 时移除该属性，比手动判断更安全

LINQ to XML 查询性能陷阱：Descendants() 不是免费的

doc.Descendants("node") 看似方便，但它会遍历整个 XML 树（深度优先），即使目标节点只在顶层。当 XML 超过 10KB 或含大量嵌套节点时，性能下降明显，且无法利用索引。

• 优先用 doc.Root.Elements("child") 或 doc.Root.Element("section")?.Elements("item") 明确层级
• 需要模糊匹配时，用 doc.Root.Descendants().Where(e => e.Name.LocalName.Equals("node", StringComparison.OrdinalIgnoreCase)) 避免命名空间干扰
• 频繁查询同一文档？把常用节点缓存为 IEnumerable，但注意 XContainer.Nodes() 返回的是实时视图，缓存需调用 .ToList()

真正难的不是语法，而是理解 XNode 层次中 XText、XCData、XComment 这些“非元素”节点如何影响 Nodes() 和 Elements() 的行为——它们都算 XNode，但只有 XElement 才能被 Elements() 返回。漏掉这个细节，First() 就可能抛异常。