“Root element is missing”错误主因是源为空、路径错、编码不匹配或流位置偏移；应先验证文件存在与内容，加载流前重置Position，中文需显式指定UTF8编码；LINQ to XML中XDocument.Load()保留完整结构，XElement.Load()仅提取根元素；保存时需用带BOM的StreamWriter或设置XDeclaration防乱码；XmlDocument非线程安全，XDocument/XElement不可变故天然支持多线程读；大数据量宜用XmlReader流式解析；命名空间必须显式声明并参与查询。
XmlDocument 加载时抛出 “Root element is missing” 错误
这通常不是 XML 内容真丢了根节点，而是文件为空、路径错、编码不匹配，或流被提前读取过。用 XmlDocument.Load() 前必须确认源可读且非空。
- 先用
File.Exists()和File.ReadAllText()看原始内容，避免黑盒加载 - 如果从
Stream加载，确保流位置在开头（stream.Position = 0），否则Load()会从当前位置读，可能直接到末尾 - 中文内容出问题？显式指定编码：用
new StreamReader(path, Encoding.UTF8)包一层再传给Load()，别依赖自动探测 -
LoadXml()只接受字符串，且要求严格格式——开头不能有 BOM 或空白行，否则报错位置极难定位
LINQ to XML 中 XDocument.Load() 和 XElement.Load() 的区别
二者底层都解析 XML，但语义和返回值不同，选错会导致后续代码多绕一倍。
-
XDocument.Load()返回完整文档对象，包含Declaration、ProcessingInstruction、根元素等全部结构；适合需要保留注释、XML 声明或处理多根节点（如 XInclude）的场景 -
XElement.Load()只提取根元素及其子树，忽略声明、注释、处理指令；更轻量，日常增删改查够用，且 API 更直觉（element.Element("child")而非doc.Root.Element("child")） - 如果 XML 文件带
，又用XElement.Load()，它不会报错，但你拿不到声明信息——这不是 bug，是设计如此
用 LINQ to XML 修改节点后保存，中文变乱码
根本原因：默认保存用 UTF-8 无 BOM 编码，但某些编辑器（如旧版记事本）打开时误判为 ANSI，显示为乱码。这不是数据损坏，是编码声明缺失。
- 保存时显式指定编码：用
doc.Save(new StreamWriter(path, false, Encoding.UTF8))，确保写入 BOM（UTF8 编码带 BOM 的StreamWriter构造函数第三个参数设为true） - 更稳妥的做法是用
XDocument.Declaration显式设置编码：在保存前加doc.Declaration = new XDeclaration("1.0", "utf-8", "yes"); - 别用
File.WriteAllText()直接写doc.ToString()，它不走 XML 序列化逻辑，会丢失缩进、编码声明，还可能把特殊字符转义错
XmlDocument 和 LINQ to XML 性能与线程安全差异
不是“谁更快”，而是“谁更适合当前任务”。盲目替换可能引入新问题。
-
XmlDocument是基于 DOM 的老模型，所有节点可随时修改、遍历，但它是**非线程安全**的——多个线程同时调用SelectNodes()或AppendChild()会崩溃，必须手动加锁 -
XDocument/XElement是不可变模型（immutable by design），创建后节点不可原地修改；每次“修改”其实是生成新对象（.Add()、.ReplaceWith()都返回新树）。所以天然支持多线程读，但频繁更新会触发较多 GC - 大数据量（>10MB）解析？两者都会吃内存；此时应考虑
XmlReader流式读取，而不是硬扛 DOM - 项目已用大量
XmlDocument+ XPath？别为了“新”强行切 LINQ to XML——XPath 在XDocument中要靠.XPathSelectElements()扩展方法，需引用System.Xml.XPath，且部分语法支持不一致
实际改 XML 时，最常被忽略的是命名空间处理——XNamespace 必须显式声明并参与所有查询，漏一个 ns + "elem" 就查不到节点，连调试输出都看不出毛病。
