.NET Framework与.NET Core/.NET 5+的XML API高度兼容，但底层实现、DTD处理（Core默认禁用）、编码推断（Core更严格遵循声明/BOM）、XPath/XSLT支持（Core需额外包且功能略简）、XmlSerializer空元素处理等存在关键差异。
.NET Framework 和 .NET Core（以及后续统一的 .NET 5+）在 XML 处理上核心 API 高度一致，但底层实现、默认行为、跨平台支持和部分高级功能存在关键差异。简单说：**你写的大部分 XmlDocument、XDocument、XmlSerializer 代码能直接迁移，但某些细节（如 DTD 处理、编码推断、XPath 引擎）可能表现不同，尤其在非 Windows 环境下。**
XML 解析器默认行为有区别
.NET Framework 默认使用基于 MSXML 的旧式解析器（尤其在 WebForms 或某些配置场景），对 DTD、实体引用等更宽松（但也更不安全）。.NET Core 从一开始只内置 System.Xml.XmlReader/XmlWriter 的轻量级、纯托管实现，禁用 DTD 处理（防止 XXE 攻击），且不支持外部实体解析 —— 这是默认安全策略，无需额外配置。
- 若需兼容旧逻辑（如读取含 DTD 的遗留 XML），必须显式创建 XmlReaderSettings 并设置 DtdProcessing = DtdProcessing.Parse（但强烈不建议）
- .NET Core 不提供 XmlValidatingReader（已废弃），验证应通过 XmlSchemaSet + XmlReader.Create 实现
编码检测与字符串处理更严格
.NET Framework 在读取 XML 文件时有时会“猜测”编码（比如看到 UTF-8 BOM 就用 UTF-8，没 BOM 可能回退到系统默认编码），而 .NET Core 更严格遵循 XML 声明（<?xml version="1.0" encoding="UTF-8"?>）或字节流 BOM。如果声明与实际编码不符，.NET Core 更容易抛出 XmlException。
通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。
- 推荐始终显式指定编码：用 FileStream + Encoding.UTF8 构造 XmlReader，避免依赖自动检测
- 使用 StringReader 传入 XML 字符串时，确保字符串本身编码正确（.NET 中 string 是 UTF-16，无需指定编码）
XPath 和 XSLT 支持范围不同
XPathDocument 和 XslCompiledTransform 在 .NET Framework 中功能完整，支持 XPath 1.0 全集及 XSLT 1.0。.NET Core 初期仅提供基础 XPath 支持（XDocument.XPathSelectElements），直到 .NET 6 才正式加入 System.Xml.Xsl 包（需手动安装 NuGet 包 System.Xml.Xsl），且 XSLT 功能仍比 .NET Framework 略精简（例如不支持脚本嵌入）。
- 简单 XPath 查询（如
//book/title）在两者中行为一致 - 复杂 XSLT 转换、自定义函数、document() 函数调用，在 .NET Core/.NET 5+ 中需确认目标运行时版本并引入对应包
序列化（XmlSerializer）行为基本一致，但有细微差别
XmlSerializer 的核心序列化逻辑在两个平台高度兼容，但以下情况需注意：
- .NET Core 中 XmlSerializer.Deserialize 对空元素（
<Name />）反序列化为 null 或默认值的行为更严格，取决于类型是否可空 - 若类含 [XmlAttribute] 且属性为 DateTime?，.NET Framework 可能接受空字符串，.NET Core 更倾向抛异常 —— 建议用 XmlIgnore + 自定义 getter/setter 控制
- 生成的 XML 声明（
<?xml ...?>）默认存在，但若用 XmlWriterSettings.OmitXmlDeclaration = true，两者都生效
基本上就这些。迁移 XML 相关代码时，95% 无需修改；重点检查 DTD、编码来源、XSLT 使用和反序列化的边界输入即可。
