我想看看这些建议的解决方案中哪种效果最好，所以我进行了一些比较测试。出于兴趣，我还将LINQ方法与Greg建议的普通的System.Xml方法进行了比较。这种变化很有趣，而不是我所期望的，最慢的方法要比最快的方法慢3倍以上。
结果按最快到最慢的顺序排序：
- CreateReader-实例猎人（0.113秒）
- 普通的旧System.Xml-格雷格·霍尔曼（0.134秒）
- 使用字符串连接聚合-Mike Powell（0.324秒）
- StringBuilder-Vin（0.333秒）
- String.Join加入数组-Terry（0.360秒）
- 数组上的String.Concat-Marcin Kosieradzki（0.364）
方法
我使用了一个具有20个相同节点（称为“提示”）的XML文档：
<hint>
<strong>Thinking of using a fake address?</strong>
<br />
Please don't. If we can't verify your address we might just
have to reject your application.
</hint>
上面显示为秒的数字是提取20个节点（连续1000次）的“内部XML”并取5次运行的平均值（均值）的结果。我没有包括将XML加载并解析为XmlDocument（对于System.Xml方法）或XDocument（对于所有其他方法）所花费的时间。
我使用的LINQ算法是：（C＃-全部使用XElement“父”并返回内部XML字符串）
CreateReader：
var reader = parent.CreateReader();
reader.MoveToContent();
return reader.ReadInnerXml();
用字符串连接聚合：
return parent.Nodes().Aggregate("", (b, node) => b += node.ToString());
StringBuilder：
StringBuilder sb = new StringBuilder();
foreach(var node in parent.Nodes()) {
sb.Append(node.ToString());
}
return sb.ToString();
String.Join数组：
return String.Join("", parent.Nodes().Select(x => x.ToString()).ToArray());
数组上的String.Concat：
return String.Concat(parent.Nodes().Select(x => x.ToString()).ToArray());
我没有在这里显示“普通的System.Xml”算法，因为它只是在节点上调用.InnerXml。
结论
如果性能很重要（例如，很多XML，需要经常解析），那么我会每次都使用Daniel的CreateReader方法。如果您只是在进行一些查询，则可能要使用Mike更简洁的Aggregate方法。
如果您在具有许多节点（可能是100个）的大型元素上使用XML，那么您可能会开始发现使用StringBuilderAggregate方法带来的好处，而不是over CreateReader。我不认为Joinand Concat方法在这些情况下会更有效，因为将大列表转换为大数组（即使在这里使用较小的列表也很明显）会带来麻烦。