XmlReader是唯一靠谱的选择，因其流式解析不加载全文档到内存，避免OOM；而XmlDocument和XDocument会全量加载导致内存爆炸。
XmlReader 为什么是唯一靠谱的选择
因为 XmlDocument 和 XDocument 会把整个 XML 加载进内存，GB 级文件直接 OOM。而 XmlReader 是只读、前向、流式解析器——它不建树，不回溯，内存占用基本恒定在几 MB 内，只取决于你缓存了多深的节点内容。
常见错误现象：OutOfMemoryException 在调用 Load() 或 Parse() 时爆发；或者 CPU 占满、程序卡死十几分钟没响应。
使用场景：日志归档 XML、大型设备导出数据、金融报文（如 FIXML）、GIS 元数据等含百万级 <record></record> 的扁平结构。
怎么写一个安全的逐节点循环
核心是别用 ReadToFollowing() 或 ReadToDescendant() 做深度跳转——它们内部会吃掉大量节点，容易漏掉同级关键字段。必须用纯 Read() + NodeType 判断推进。
实操建议：
- 始终检查
reader.NodeType == XmlNodeType.Element，再读reader.Name，避免把XmlNodeType.Whitespace或XmlNodeType.Comment当成有效节点 - 遇到目标元素（比如
<order></order>）后，用reader.ReadSubtree()拿子阅读器处理其内部，原阅读器继续向前，不干扰主流程 - 别在循环里反复调用
GetAttribute("xxx")——先用MoveToFirstAttribute()+ReadAttributeValue()批量提取，减少属性游标重置开销
示例片段：
Node.js 可靠编程技能。避免事件循环阻塞、异步陷阱、ESM 兼容问题和内存泄漏。触发词：Node.js 开发、async/await、流处理、性能优化、安全编码。
while (reader.Read())
{
if (reader.NodeType == XmlNodeType.Element && reader.Name == "order")
{
var orderReader = reader.ReadSubtree();
ProcessOrder(orderReader); // 单独函数处理该 order 下所有子节点
orderReader.Close(); // 必须关！否则 reader 位置错乱
}
}属性、文本、嵌套层级的坑怎么绕
XmlReader 对文本内容极其“吝啬”：调用 ReadElementContentAsString() 会自动跳过注释和空白，但也会吞掉紧邻的 <price>12.5</price><!-- VAT included --> 中的注释——如果你依赖注释做业务标记，这就丢数据了。
容易踩的坑：
-
ReadElementContentAsInt()遇到空字符串或空白直接抛FormatException，不是返回 0 —— 必须先IsEmptyElement判断，再用ReadContentAsString()+int.TryParse() - 嵌套结构（比如
<user><profile><name>...</name></profile></user>）不能靠缩进或深度计数判断层级——Depth属性不可靠（注释、CDATA 会影响），应靠StartElement/EndElement事件式配对 - 如果 XML 含命名空间，
reader.Name返回的是prefix:localName，但reader.LocalName才是真实标签名；用reader.IsStartElement("user")会失败，得用reader.IsStartElement("user", "http://ns.example.com")
性能关键点：缓冲、编码、验证关不关
默认构造的 XmlReader.Create(stream) 会启用 DTD 处理和命名空间验证，GB 文件里每秒触发上百次外部实体检查，速度直接掉 3–5 倍。
必须做的配置：
- 关 DTD：
new XmlReaderSettings { DtdProcessing = DtdProcessing.Ignore } - 关命名空间验证（除非真需要）：
IgnoreComments = true、IgnoreProcessingInstructions = true - 显式指定编码（尤其当文件无 BOM 且是 UTF-8）：
XmlReader.Create(stream, new XmlReaderSettings { Encoding = Encoding.UTF8 }) - 用
BufferedStream包一层原始文件流（4KB 缓冲足够），避免 .NET 底层频繁 syscall
实测：某 2.3GB 日志 XML，关 DTD + 关注释 + 缓冲流后，解析耗时从 18 分钟降到 3 分 20 秒。
真正难的不是读完，是边读边做聚合、去重、跨节点关联——这时候别硬扛，该切分就切分，该写临时索引就写。XML 本身不是数据库，别把它当数据库用。
