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<XElement>，但注意XContainer.Nodes()返回的是实时视图，缓存需调用.ToList()
真正难的不是语法，而是理解 XNode 层次中 XText、XCData、XComment 这些“非元素”节点如何影响 Nodes() 和 Elements() 的行为——它们都算 XNode，但只有 XElement 才能被 Elements() 返回。漏掉这个细节，First() 就可能抛异常。
