XmlReader 解析上传流必须直接使用 IFormFile.OpenReadStream() 返回的 Stream，禁用 DTD、启用 CloseInput，并逐节点读取以节省内存；避免先转 string 或用 XDocument 加载全量 XML。
XmlReader 读取上传流必须用 Stream 而不能用 string
ASP.NET Core 中接收文件上传时，IFormFile.OpenReadStream() 返回的是一个未缓冲的、只读的 Stream。如果先调用 file.ReadAllTextAsync() 或转成 string 再用 XmlReader.Create(string)，会丢失流位置、触发完整内存加载，且无法应对大文件——这直接破坏了 XmlReader 的流式优势。
正确做法是把原始 Stream 直接传给 XmlReader.Create()，并显式设置 XmlReaderSettings.DtdProcessing = DtdProcessing.Prohibit（防 XXE）和 XmlReaderSettings.CloseInput = true（让 Reader 自动释放流）：
var settings = new XmlReaderSettings
{
DtdProcessing = DtdProcessing.Prohibit,
CloseInput = true,
IgnoreWhitespace = true
};
using var reader = XmlReader.Create(file.OpenReadStream(), settings);
逐节点解析比 XDocument.Load() 节省内存且可控性更强
XDocument.Load() 会将整个 XML 加载进内存构建成 DOM 树，哪怕你只关心其中几个字段，也要为全部节点分配对象、维护父子关系、缓存文本内容。而 XmlReader 是前向只读游标，一次只持有当前节点，内存占用基本恒定（约几十 KB），适合处理几十 MB 甚至上百 MB 的 XML 文件。
逐节点解析的关键在于主动控制读取节奏，常见模式包括：
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
- 用
reader.Read()推进到下一个节点，配合reader.NodeType判断类型（XmlNodeType.Element/XmlNodeType.Text/XmlNodeType.EndElement） - 遇到目标元素（如
<Order>）时，用reader.ReadSubtree()提取子树做局部解析，避免手动跳过无关内容 - 用
reader.MoveToFirstAttribute()+reader.MoveToNextAttribute()遍历属性，比正则或字符串拆分更健壮 - 对文本内容，必须用
reader.ReadElementContentAsString()或reader.ReadContentAsString()，而非直接读reader.Value（后者在混合内容下不可靠）
XmlReader 解析上传流时容易踩的三个坑
实际部署中这几个问题高频出现，且错误信息不直观：
-
InvalidOperationException: Root element is missing：多数因为上传流已被其他代码提前读取过（比如日志中间件调用了Request.Body.ToString()），导致流位置在末尾。解决方法是确保只读一次，或在中间件里用EnableBuffering()并Request.Body.Seek(0, SeekOrigin.Begin) - 中文乱码：上传流默认编码可能是 UTF-8 无 BOM，但某些客户端发来带 BOM 的 UTF-8，
XmlReader会误判为 UTF-16。显式指定编码可规避：XmlReader.Create(stream, settings, "UTF-8") - 空元素解析异常：像
<Price />这类自闭合标签，reader.NodeType是XmlNodeType.Element，但紧接着reader.IsEmptyElement为true；若后续直接调ReadElementContentAsString()会抛异常，应先判断再读
什么时候不该用 XmlReader 逐节点解析
不是所有 XML 场景都适合手写状态机。以下情况建议退回到 XDocument 或 XmlSerializer：
- XML 结构固定且简单，比如配置片段，用
XmlSerializer.Deserialize<Config>(stream)更安全、少出错 - 需要随机访问父/兄弟节点，或频繁 XPath 查询，DOM 模型天然支持，
XmlReader得自己缓存上下文 - XML 含大量命名空间，手动处理
reader.LookupNamespace()和前缀映射极易遗漏，XDocument自动维护更省心 - 调试阶段需快速验证逻辑，
XmlReader的单步推进调试体验远不如对象绑定直观
逐节点解析真正发挥价值的地方，是那些结构松散、体积大、字段稀疏、且对内存和延迟敏感的上传场景——比如物流报文、银行对账文件、工业传感器批量上报。这时候每行代码都在和流的位置、节点边界、编码容错打交道，没捷径可抄。
