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（如
xmlhttprequestnpm 包）在 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
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
