在C#开发中，LINQ to XML提供的XElement类型以其函数式、不可变和易查询的特性被广泛使用，而很多遗留类库或系统接口仍然要求传入基于XmlDocument模型的XmlElement对象。由于这两套XML API分属不同命名空间与对象体系，运行时并不能直接强制转换，开发者必须借助中间机制完成映射。
为什么不能直接强转
XElement位于System.Xml.Linq命名空间，是LINQ to XML的核心类，它以一种轻量的方式构建XML信息集；而XmlElement位于System.Xml命名空间，是传统DOM（文档对象模型）的一部分，必须依附于XmlDocument才能存在。它们在底层是完全不同的类型继承链，XElement并不继承自XmlNode，因此类似下面的写法在运行时会抛出InvalidCastException。
XElement xEl = new XElement("root", new XElement("child", "text"));
// 下面这行编译能通过，但运行时会报错
XmlElement xmlEl = (XmlElement)xEl;
除了类型系统层面的隔离，二者对命名空间、空白处理以及节点父子关系的维护方式也有差异。直接转换不仅不可行，还可能让调用方误以为拿到了可写回原文档的节点，从而引发更难排查的状态不一致问题。
使用XmlReader进行桥接转换
最稳妥且被官方推荐的做法是利用XmlReader作为桥梁。XElement提供了CreateReader方法，可以生成一个向前只读的游标；XmlDocument则提供了ReadNode方法，能从XmlReader当前位置读取一个完整节点并返回XmlNode，此时再将其转为XmlElement即可。
using System;
using System.Xml;
using System.Xml.Linq;
class Program
{
static void Main()
{
XElement xElement = new XElement("user",
new XAttribute("id", 1),
new XElement("name", "张三"));
XmlDocument doc = new XmlDocument();
// 创建基于XElement的读取器
using (XmlReader reader = xElement.CreateReader())
{
// 将读取器当前节点读入XmlDocument
XmlNode node = doc.ReadNode(reader);
if (node is XmlElement element)
{
// 此时element就是可用的XmlElement
Console.WriteLine(element.OuterXml);
}
}
}
}
这种方式的优势在于不会破坏原有的XElement树，转换过程也不依赖字符串序列化，性能较好，并且能完整保留命名空间与属性信息。由于使用了using语句，读取器会被正确释放，避免资源泄漏。需要注意的是，ReadNode会消费读取器位于的当前元素，若后续还要继续读取其他兄弟节点，应在循环或恰当位置控制游标。
处理命名空间场景
当XElement带有命名空间时，CreateReader默认会输出带前缀的命名空间声明，ReadNode也能正确识别并生成对应的XmlElement。如果目标XmlDocument需要统一的命名空间管理器，可以在读取后通过doc.NameTable或XmlNamespaceManager做进一步校验，但通常情况下直接转换即可满足大多数接口要求。
通过OuterXml字符串中转
如果不希望引入XmlReader，也可以先将XElement序列化为字符串，再由XmlDocument加载该字符串，从而拿到XmlElement。这种方法代码直观，适合一次性适配或测试代码。
using System;
using System.Xml;
using System.Xml.Linq;
class Demo
{
static void Main()
{
XElement xEl = new XElement("book", new XElement("title", "C#入门"));
XmlDocument doc = new XmlDocument();
// 通过字符串加载
doc.LoadXml(xEl.ToString());
XmlElement xmlEl = doc.DocumentElement;
Console.WriteLine(xmlEl.Name);
}
}
不过这种方案存在明显短板：ToString或OuterXml会触发一次完整的XML文本序列化，随后LoadXml又要解析这段文本，产生了不必要的CPU与内存开销；而且在跨线程或大型文档场景下，临时字符串可能带来GC压力。此外，某些XElement上基于引用的注释节点或特定注解不会进入文本，转换后自然丢失。因此，仅在简单脚本或兼容老代码的临时通道中建议使用字符串中转。
方案对比与选择建议
为了更清晰地看到两种主流方式的差异，可以从性能、保真度与代码复杂度几个维度进行比较：
| 转换方式 | 性能 | 节点保真度 | 适用场景 |
|---|---|---|---|
| XmlReader桥接 | 高，无字符串分配 | 完整保留命名空间与结构 | 生产代码、高频调用 |
| OuterXml字符串 | 较低，两次解析 | 丢失注解等非文本信息 | 临时适配、测试 |
在实际架构中，如果项目已经混合使用LINQ to XML做数据组装、又必须调用只接受XmlElement的旧API，推荐封装一个静态工具方法，内部统一采用XmlReader方式，既隔离了转换细节，也方便后续替换为更高效的自定义映射。对于极少数需要把XmlElement反向转为XElement的场景，则可利用XElement.Load配合XmlReader.Create完成逆向操作，思路完全一致。
常见误区提醒
有些开发者试图通过反射强行访问XElement内部字段来构造XmlElement，这不仅依赖具体框架实现、在.NET Core与.NET Framework上行为不一致，而且会绕过类型安全检查。另一个误区是认为XElement.Save到流再让XmlDocument加载会比CreateReader更快，实际上Save底层同样基于XmlWriter序列化，并不会优于直接读取器桥接。理解两套模型的设计初衷，选用官方提供的互操作入口，才是稳定可靠的解决路径。
C#XElementXmlElement修改时间：2026-08-06 15:51:41