为什么 Axios 不太适合 PWA 中的服务工作者，为什么标准 Fetch API 是更好的选择？ [已关闭]

Question

所以，我正在制作一个 PWA 应用程序，为了获取数据，我使用了 Axios 库。但是，服务工作人员没有缓存数据。后来，经过一番谷歌搜索，我发现 Axios 不能很好地与 Service Worker 配合使用。

因此，我决定对 Axios 请求使用 wrapper，并安装了 6 年前发布的 axios-fetch。我的应用程序运行良好，但有一天，我收到 Depedabot 警报，称该库的某些部分存在漏洞，并且没有持续维护。我不得不删除这个包装器，所以我最终决定使用 fetch 重写代码。

现在，一切正常。现在的问题是为什么 Axios 不适合 Service Worker 实现。我真的很喜欢 Axios，它为我做了很多事情。在fetch中，很多事情我都要自己处理。最重要的是，我正在使用 React Query。 React Query 需要一个被拒绝的 Promise 才能正确处理错误。在axios中，当状态码超出200-299范围时，axios将拒绝promise。然而，对于 fetch 来说情况并非如此。为什么 Axios 还没有或者已经为 Service Worker 提出任何解决方案？

Answer 1

您问的问题是关于 Axios 与 Fetch API 在渐进式 Web 应用程序 (PWA) 和服务工作者的背景下的适用性。核心问题围绕缓存以及 Service Worker 如何处理请求。

Axios 是一个流行的用于发出 HTTP 请求的 JavaScript 库，它具有广泛的功能，可以使开发变得更加容易。然而，它并不是专门为与 Service Worker 一起使用而设计的，而 Service Worker 是 PWA 的核心组件。 Service Worker 充当 Web 应用程序和外部世界之间的代理，允许提供离线支持和资源缓存等功能。

Axios 可能不适合与 Service Worker 一起使用的原因之一是它在底层依赖于

XMLHttpRequest

，这与 Service Worker 使用的

Fetch

API 的请求/响应拦截模式不兼容。正如您所发现的，这可能会导致缓存问题。

另一方面，

Fetch

 API 内置于现代浏览器中，并可与服务工作线程一起本地工作。它的设计目的是让服务工作者可以轻松缓存，并支持拦截请求和响应以有效地缓存它们。

关于错误处理，

Fetch

仅在发生网络错误时拒绝承诺。否则，即使响应是 HTTP 错误状态，它也始终会解析。您需要检查响应的 

ok

 状态或状态代码来处理 HTTP 错误。此行为与 Axios 不同，Axios 自动拒绝任何超出 200-299 范围的 HTTP 状态代码的承诺。

Axios 传统上并不专注于服务工作者方面，因为它的主要用例是使 HTTP 请求更简单并为其提供更强大的 API。随着 Web 开发格局的变化、库的发展，Axios 可能会在未来解决这个问题，或者社区可能会提出包装器或插件等解决方案。

目前，如果您严重依赖服务工作者及其缓存机制，则原生

Fetch

 API 将是更兼容和更直接的选择，特别是对于您正在使用的像 React Query 这样的库，它们期望某些承诺行为。 React Query 的设计是与原生 fetch 实现配合使用，以便与 async/await 等现代 JavaScript 功能无缝集成，并确保与服务工作者的兼容性。