优先用 response.arraybuffer() + textdecoder 解码 xml 响应以避免乱码；解析前需去除 bom、校验字符串有效性并显式指定 'application/xml' 类型；注意 cors 配置与大 xml 内存开销。
Fetch 请求返回 XML 但 response.text() 报错或乱码
浏览器 fetch() 默认把响应体当字符串处理，但 XML 常含 UTF-8 BOM 或声明（如 <?xml version="1.0" encoding="UTF-8"?>），直接 response.text() 可能触发解码异常，尤其服务端未正确设 Content-Type: application/xml; charset=utf-8 时。
- 优先用
response.text()，但必须确保服务端响应头带明确charset；否则手动指定编码较麻烦（fetch不支持传解码器） - 更稳的方案是用
response.arrayBuffer()+TextDecoder：fetch('/data.xml') .then(r => r.arrayBuffer()) .then(buf => new TextDecoder('utf-8').decode(buf)) - 若 XML 含中文且服务端返回
Content-Type: text/xml却没写 charset，浏览器可能按 ISO-8859-1 解，导致乱码——这时必须靠arrayBuffer()+ 显式TextDecoder补救
XML 响应体解析成 DOM 对象失败：parseFromString 报错
DOMParser().parseFromString() 对输入极其敏感：空白、BOM、非法字符、未闭合标签都会让解析返回空文档（document.documentElement === null），且不抛错，只静默失败。
- 务必先检查原始字符串是否非空、是否以
<?xml或<root> 开头，避免把 404 HTML 页面当 XML 解析</root> - 解析前 strip BOM：
xmlStr.replace(/^\uFEFF/, '') - 使用时显式指定类型：
parser.parseFromString(xmlStr, 'application/xml')（不能用text/xml，部分浏览器不认） - 解析后立刻检查：
if (!doc || !doc.documentElement || doc.documentElement.tagName === 'parsererror') { /* 处理错误 */ }
跨域请求 XML 被拒绝：CORS 配置遗漏
XML 是资源类型，不是特殊格式，CORS 规则和 JSON 完全一致。常见误区是以为“只是 XML”就不用配 CORS，结果控制台报 Blocked by CORS policy。
- 服务端必须返回
Access-Control-Allow-Origin，且值不能是通配符*当请求带凭证（如 cookies）时 - 若前端
fetch设了credentials: 'include'，服务端还需加Access-Control-Allow-Credentials: true - 预检请求（OPTIONS）可能被忽略——如果请求含自定义 header（如
Authorization），服务端必须正确响应 OPTIONS，且 XML 接口也要支持
XML 数据量大时内存暴涨或卡顿
XML 解析为 DOM 树会生成大量节点对象，比同等 JSON 占用多 3–5 倍内存，10MB 以上 XML 很容易触发浏览器卡死或 OOM。
- 避免全量解析：改用流式解析库（如
sax或libxmljs的 WASM 版本），但需额外打包 - 服务端优先提供 JSON 接口；若必须 XML，考虑加
Accept: application/json请求头协商返回格式 - 客户端做简单校验时，别用
DOMParser全量加载，改用正则粗筛关键字段（如xmlStr.match(/<status>([^/)</status>），仅限结构稳定、无嵌套的场景
XML 的坑不在语法，而在 HTTP 层细节和浏览器解析器的隐式行为——BOM、charset、CORS、DOM 构建开销，每个都可能让请求“看起来成功”却拿不到数据。
