选对xml处理方式性能差异可达9倍：大文件用XmlReader流式解析，中小文件用XDocument高效查询，固定结构用XmlSerializer对象映射，传统dom用XmlDocument维护遗留系统。
选对xml处理方式，性能差异可能达9倍——关键不在“快不快”，而在“合不合适”。小文件随机查改用XDocument更顺手，大文件顺序读取必须上XmlReader，对象映射就交给XmlSerializer。
XmlReader：大文件流式解析的首选
XmlReader采用只进、非缓存的流式读取，内存占用恒定，不随文件大小增长。适合GB级日志、报表导入等只读场景。
- 启动快：无需加载全文即可开始提取数据，首节点访问延迟极低
- 吞吐高：实测比XmlDocument快约9倍（同3000次解析字符串测试）
- 编码稍重：需手动控制节点遍历，不支持XPath或随机访问
- 推荐搭配：ReadElementContentAsString() 提取文本、MoveToContent() 跳过空白和声明
XDocument（linq to XML）：中小型文件开发效率之王
语法现代、支持LINQ查询和函数式操作，代码简洁易维护。内部仍是内存树结构，性能与XmlDocument接近，但开发体验明显更优。
- 适合：配置文件解析、API响应处理、需多次查询或局部修改的XML
- 查询灵活：可混合使用LINQ表达式与XPath（如XPathSelectElement()），预编译XPath还能提速10%–30%
- 注意点：仍会整树加载，超50MB文件易触发GC压力或OOM
XmlDocument：传统DOM，兼容老项目但渐退场
基于完整内存树，支持XPath、事件、编辑、保存等完整DOM能力。但设计年代较早，API冗长，新项目不建议首选。
- 优势：XPath支持成熟，调试直观，适合遗留系统维护
- 短板：内存开销大、初始化慢、线程不安全（需手动加锁）
- 典型瓶颈：加载170MB XML时，峰值内存可达文件体积的3–4倍
XmlSerializer：强类型对象映射专用
当XML结构固定、且天然对应c#类时，XmlSerializer是最自然的选择。它跳过中间DOM树，直接绑定属性，序列化/反序列化路径最短。
- 适用场景：Web API请求体、配置节反序列化、DTO数据交换
- 性能特点：反序列化速度取决于类复杂度；含大量嵌套或自定义转换器时会略降速
- 限制：要求类有无参构造、属性可读写、字段需[XmlElement]等显式标注