LoadXml()仅支持格式严格、语法合法的XML字符串，不兼容HTML、JSON、含BOM或未闭合标签的文本；应预校验、去空格、设XmlResolver=null、注意编码与命名空间，并优先选用XDocument.Parse()。
LoadXML 方法只能处理格式严格的 XML 字符串
XmlDocument.LoadXml() 不是万能的字符串解析器，它要求输入必须是语法合法、结构完整的 XML 文档。常见错误是传入 HTML 片段、JSON 格式、带 BOM 的 UTF-8 字符串，或未闭合标签的“类 XML”文本——这时会直接抛出 XmlException，错误信息通常是 "Data at the root level is invalid." 或 "Unexpected end of file."。
实操建议：
- 先用
XmlReader.Create(new StringReader(xmlString))+XmlReaderSettings.DtdProcessing = DtdProcessing.Prohibit做预校验，避免异常打断流程 - 如果字符串来自前端或日志，务必用
xmlString.Trim()清除首尾空白，否则可能因开头换行+UTF-8 BOM 导致解析失败 - 不推荐对用户输入直接调用
LoadXml()；应先做白名单过滤（如只允许<root>、<item>等已知标签）
LoadXML 和 Load 区别：一个吃字符串，一个吃流/路径
LoadXml() 只接受 string，而 Load() 接收 Stream、TextReader 或文件路径。误把文件路径传给 LoadXml() 是高频低级错误，比如写成 doc.LoadXml("C:\data.xml") —— 它不会去读文件，而是尝试把这串路径当 XML 解析，必然失败。
实操建议：
- 明确意图：要加载本地文件？用
doc.Load("path.xml")；要解析内存中拼出来的 XML？才用doc.LoadXml(xmlString) - 若字符串含外部 DTD 或实体引用（如
XmlDocument.XmlResolver = null并禁用 DTD - 注意编码：
LoadXml()默认按 UTF-16 解析，若字符串是 UTF-8 且含非 ASCII 字符（如中文），但没声明<?xml version="1.0" encoding="utf-8"?>，可能乱码
解析失败时，别只看异常消息，要检查实际字符串内容
很多开发者复制异常堆栈里的“XML”片段去调试，结果发现那只是截断的前 100 字符，真实问题可能在末尾——比如少了一个 </root>，或某处用了中文全角引号 “” 替代英文双引号 ""。
实操建议：
- 打印原始字符串长度：
Console.WriteLine($"Length: {xmlString.Length}")，长度为 0 或超大（>1MB）都值得警惕 - 用
System.Text.Encoding.UTF8.GetBytes(xmlString)查看字节流，确认是否有隐藏控制字符（如u0000、uFEFF） - 临时写入文件再用浏览器或 VS 打开验证：
File.WriteAllText("debug.xml", xmlString)，比纯脑补高效得多
替代方案：XDocument 更适合现代 C# 场景
如果你用的是 .NET 3.5+，XDocument.Parse() 比 XmlDocument.LoadXml() 更轻量、LINQ 支持更好，且对空白和编码更宽容。它不是“替代”，而是“更推荐”的选择——尤其当你后续要做查询、修改或序列化。
实操建议：
- 简单加载：用
var doc = XDocument.Parse(xmlString)；需要容错可包一层 try/catch +XDocument.Load(XmlReader.Create(...)) - 若必须返回
XmlDocument（如对接老接口），可用doc.ToXmlDocument()（需引用System.Xml.XPath） - 注意性能差异：
XDocument是函数式不可变模型，频繁修改不如XmlDocument高效；但纯解析+读取场景，它更快更稳
最常被忽略的一点：XML 命名空间。哪怕字符串里没显式写 xmlns，如果节点实际属于某个命名空间（比如从 SOAP 响应里抠出来的），用 GetElementsByTagName() 就查不到——必须用带命名空间前缀的 SelectNodes() 或 XNamespace。这点不踩一次坑很难记住。
