Worker 中推荐使用 Fetch API 而非 XMLHttpRequest：Fetch 原生支持、语法一致、功能完整；XHR 需 polyfill 且兼容性差，仅在必须使用其特有功能时考虑。

Worker 线程内不能直接使用 XMLHttpRequest，但可以原生使用 Fetch API。

Fetch API：开箱即用，推荐首选

Web Worker 拥有独立的全局作用域（self），其中内置了 fetch 方法。无需 polyfill 或额外引入，语法与主线程完全一致：

• 支持 async/await 和 .then() 链式调用
• 可传入完整配置对象（method、headers、body、credentials 等）
• 响应处理（如 response.json()、response.text()）照常可用
• 流式读取（response.body.getReader()）在 Worker 中同样生效

XMLHttpRequest：不原生支持，需绕行方案

Worker 环境中没有 window 对象，也没有内置 XMLHttpRequest 构造函数。若强行使用，必须依赖外部 polyfill：

• 通过 importScripts('xhr-polyfill.js') 加载兼容版本
• polyfill 需自行实现事件模拟、状态管理等逻辑，稳定性与性能不如原生 fetch
• 主流 polyfill（如 xmlhttprequest npm 包）在 Worker 中表现有限，且不支持所有 XHR 特性（如上传进度监听）

关键差异与注意事项

两者在 Worker 中的行为存在本质区别：

• Credentials 默认行为不同：fetch 默认不发 Cookie，必须显式设 credentials: 'include'；XHR 的 withCredentials = true 同样需手动开启
• 错误边界更清晰：fetch 只在网络失败时 reject（如 DNS 错误、离线），HTTP 错误码（如 404、500）仍返回 response，需手动判断 response.ok
• 无 DOM 依赖：两者都不访问 DOM，但 fetch 更轻量、无事件循环干扰，更适合长时间后台任务（如轮询、消息同步）

实际建议

除非维护遗留系统或必须依赖 XHR 特有功能（如 upload.onprogress），否则应统一使用 fetch：

• 新项目直接用 fetch，代码简洁、调试友好、生态成熟
• 已有 XHR 逻辑迁移到 Worker 时，优先重写为 fetch
• 需要中断请求？fetch 支持 AbortController，XHR 则需手动 abort