XML曾经是数据交换的主流格式，即便今天JSON大行其道，很多遗留系统、配置文件、RSS订阅以及SOAP接口依然依赖XML。而在前端直接解析XML时，一个很常见的现象是：同一段XML字符串，在Chrome中解析得好好的，换到IE或者某些老版本浏览器中就出现节点丢失、报错甚至解析失败。这背后的根本原因在于，不同浏览器内置的XML解析器实现并不相同，对规范的遵循程度、错误处理方式、空白节点处理策略都存在差异。本文就来系统地梳理这些差异，并给出兼容性处理方案。
一、解析器实现层面的差异
现代浏览器（Chrome、Firefox、Edge、Safari）统一使用DOMParser对象来解析XML字符串，这是W3C DOM标准定义的接口。它的用法很简单：
var parser = new DOMParser();
var xmlDoc = parser.parseFromString(text, "text/xml");
// 检查解析错误
var err = xmlDoc.getElementsByTagName("parsererror");
if (err.length > 0) {
console.log("解析失败");
}
而IE9之前的浏览器走的是完全另一条路，依赖ActiveX控件Microsoft.XMLDOM。它是一个COM对象，用法与标准接口差别很大：
var xmlDoc = new ActiveXObject("Microsoft.XMLDOM");
xmlDoc.async = false;
xmlDoc.loadXML(text);
if (xmlDoc.parseError.errorCode !== 0) {
console.log(xmlDoc.parseError.reason);
}
这两套API的差异不仅是调用方式不同，更关键的是行为细节。比如DOMParser解析失败时不会抛异常，而是返回一个包含<parsererror>节点的文档；而XMLDOM解析失败后可以通过parseError对象拿到具体的错误行号和原因描述，错误信息反而更详细。开发者如果只按标准接口写错误处理逻辑，在IE上就会直接失效。
另外一个容易被忽视的差异是异步行为。Microsoft.XMLDOM默认async属性为true，如果不显式设置为false，代码会在文档尚未加载完成时就继续执行，导致拿到空文档。这是老项目从IE迁移到现代浏览器时经常遇到的诡异问题。
二、空白文本节点的处理差异
XML允许在标签之间书写换行和缩进，这些空白字符在文档对象模型中会形成文本节点。问题在于，不同浏览器对这些空白文本节点的保留策略不一致，这直接影响了childNodes的遍历结果。
举例来说，下面这段XML：
<root>
<item>数据</item>
</root>
在部分浏览器中，root的子节点包含三个：一个空白文本节点、<item>元素节点、再一个空白文本节点。而在另一些浏览器或设置了某些解析选项后，空白节点可能被忽略，root只有一个子节点。如果代码里写了firstChild去取<item>元素，在前者拿到的是空白文本节点，取nodeName会得到#text而不是预期的标签名。
稳妥的做法有两种。第一种是统一使用getElementsByTagName或children属性代替childNodes，因为它们只返回元素节点，天然屏蔽了空白文本的干扰。第二种是在解析前用正则把标签之间的空白清理掉：
text = text.replace(/>\s+</g, "><");
不过要注意，这种粗暴替换会破坏含有xml:space="preserve"属性的文档，以及那些本身就有意义的空白内容，使用前需确认业务场景是否允许。
三、命名空间、DTD与外部实体加载的差异
XML命名空间在SOAP、SVG等场景中大量出现，浏览器对命名空间的支持程度也参差不齐。使用getElementsByTagName查询带命名空间前缀的标签时，有的浏览器要求写完整的前缀形式如soap:Body，有的则可以用getElementsByTagNameNS配合命名空间URI查询。IE的XMLDOM甚至提供了独有的selectNodes方法配合XPath表达式查询，返回结果的节点集合还是"活的"，而标准接口的querySelectorAll返回的是静态集合，这种差异会让依赖集合实时性的代码在不同浏览器下表现不同。
DTD和外部实体是安全问题的重灾区，也是差异最大的地方。早期的Microsoft.XMLDOM默认会加载外部DTD并对实体进行展开，如果XML中引用了外部实体，浏览器会真的去发起网络请求，这带来了XXE（XML外部实体注入）的风险。而现代浏览器的DOMParser出于安全考虑，基本禁止了外部实体的解析，遇到未声明的实体直接判定为解析错误。这就导致同一段包含自定义实体的XML，在老浏览器中能正常解析，在新浏览器中直接失败。
此外，对XML声明头的处理也有细微差别。比如<?xml version="1.0" encoding="gb2312"?>这样的声明，Chrome会尝试按声明的编码解析，而某些环境下的Firefox对非UTF-8编码的支持有限，可能返回乱码或错误。跨浏览器传递XML时，最保险的方式是统一转成UTF-8编码。
四、如何写出跨浏览器兼容的解析代码
理解了差异来源，兼容处理就有了明确思路。核心策略是封装一个统一的解析函数，内部做浏览器能力检测：
function parseXML(text) {
var xmlDoc = null;
if (window.DOMParser) {
var parser = new DOMParser();
xmlDoc = parser.parseFromString(text, "text/xml");
if (xmlDoc.getElementsByTagName("parsererror").length > 0) {
return null; // 标准浏览器解析失败
}
} else if (window.ActiveXObject) {
xmlDoc = new ActiveXObject("Microsoft.XMLDOM");
xmlDoc.async = false;
xmlDoc.loadXML(text);
if (xmlDoc.parseError.errorCode !== 0) {
return null; // IE解析失败
}
}
return xmlDoc;
}
这段代码先检测DOMParser是否存在，优先走标准路径；只有老IE环境才降级到ActiveX方案。两套解析器各自的错误检测逻辑都做了封装，调用方拿到的结果行为一致。
如果项目对兼容性要求更高，或者需要强大的查询能力，可以考虑引入第三方库。老牌的jquery-xml插件、xml2js（Node端常用）、以及基于XPath的xpath库都能在统一的抽象层上屏蔽浏览器差异。它们的原理大多是自己实现了一遍XML词法分析，不依赖浏览器原生解析器，因此行为完全可控。
最后需要提醒一点：如果只是简单的数据读取，能不用XML就尽量不用。把XML在后端转换成JSON再传给前端，是规避所有浏览器解析差异最彻底的办法。只有在必须直接处理XML的场景下，才需要认真对待上面这些兼容细节，并做好充分的自动化测试，覆盖主流浏览器的各种边界情况，这样才能保证解析行为的一致性。