XmlReader比XmlDocument更适合大文件，因其流式读取内存恒定几KB，而XmlDocument需全量加载易爆内存；适用于>10MB文件或内存受限场景，不适用需随机访问或XPath查询的场景。
XmlReader 为什么比 XmlDocument 更适合大文件
因为 XmlDocument 会把整个 XML 加载进内存构建成 DOM 树，100MB 的文件可能吃掉 500MB+ 内存；XmlReader 是只进、流式读取，内存占用基本恒定在几 KB —— 这不是“推荐”，是唯一能不崩的选法。
- 适用场景：XML 文件 > 10MB，或内存受限（如 ASP.NET Core 后端处理上传的报表 XML）
- 不适用场景：需要随机访问节点、频繁 XPath 查询、反复回溯 —— 那就别硬扛，换
XDocument或分块预处理 - 注意
XmlReader.Create()默认启用 DTD 解析，若源 XML 带外部实体（如），可能引发 XXE 攻击；务必禁用：<pre class="brush:php;toolbar:false;">var settings = new XmlReaderSettings { DtdProcessing = DtdProcessing.Ignore };</pre>
如何安全跳过无关节点并精准定位目标数据
XmlReader 没有“找某个子节点”这种便利方法，必须手动推进游标。靠 ReadToFollowing() 或 ReadToDescendant() 容易漏数据或抛 XmlException —— 因为它们只匹配起始标签，而实际 XML 可能夹杂注释、空白、CDATA。
- 正确做法：用
reader.NodeType == XmlNodeType.Element && reader.Name == "TargetNode"配合reader.Read()循环判断 - 读取文本内容时，不要直接用
reader.Value，它可能为空（比如节点含子元素）；应调用reader.ReadElementContentAsString()或先reader.Read()再取reader.Value - 遇到嵌套结构（如
<order><item>...</item><item>...</item></order>），用reader.IsEmptyElement判断是否自闭合，再用reader.Read()跳过结束标签，避免重复读取
性能关键：Read() 调用次数和字符串分配怎么省
每调一次 Read() 都有状态机开销，而反复调 reader.GetAttribute("id") 会触发内部字符串解析 —— 这些在循环里放大后就是瓶颈。
- 用
reader.MoveToContent()一次性跳过空白/注释，比手动Read()判类型快 - 属性值尽量用
reader.GetAttribute(int index)而非GetAttribute(string name)，避免哈希查找；索引可通过reader.AttributeCount和reader.MoveToAttribute(i)预先确认 - 避免在循环里拼接字符串（如
sb.Append(reader.Value)），改用reader.ReadContentAsString()直接获取解码后的值，减少中间char[]分配
常见崩溃点：编码识别失败和命名空间陷阱
XML 声明里写 <?xml version="1.0" encoding="GB2312"?>，但 .NET 默认用 UTF-8 解码流，直接传 FileStream 会乱码甚至抛 XmlException: Invalid character in the given encoding。
- 必须显式指定编码：用
new StreamReader(fileStream, Encoding.GetEncoding("GB2312"))包一层，再传给XmlReader.Create() - 带命名空间的 XML（如
<rss xmlns="http://purl.org/rss/1.0/"></rss>）中，reader.Name返回的是带前缀的全名（如{http://purl.org/rss/1.0/}channel），直接比对"channel"必然失败；要用reader.LocalName == "channel" - 如果 XML 里混用默认命名空间和带前缀的命名空间（如
<root xmlns="a"><child xmlns:b="b"></child></root>），LocalName仍可用，但注意reader.NamespaceURI在每个节点处会动态变化
最麻烦的不是语法，是有些 XML 导出工具（比如老旧 ERP 系统）会把 CDATA 块里塞进未转义的 或 <code>&，导致 XmlReader 在解析时直接报错 —— 这时候只能前置用正则粗筛，或改用容错更强的第三方库（如 SharpXml），但那就脱离 .NET 原生了。
