Axios 1.20.0 在 Workers 报 Unsupported cache mode: default

浏览器请求正常，Cloudflare Worker 中同一段 Axios 调用却在发出请求前失败：

TypeError: Unsupported cache mode: default

若实际打包的是 Axios 1.20.0，并使用 fetch adapter，检查最终传给 Request 的 cache。这一版会补入 cache: 'default'；Workers 的 Request 只接受未指定、no-store 或 no-cache，显式传入 default 会被拒绝。错误发生在请求构造阶段，调整服务端跨域头、重试次数或连接超时都不能改变这个参数。

给 Worker 使用的实例明确设置 cache

在现有服务端请求实例上加入运行时支持的值：

import axios from 'axios';

export const workerHttp = axios.create({
  adapter: 'fetch',
  fetchOptions: {
    cache: 'no-store',
  },
});

这是一份实例配置。已有 baseURL、认证、超时和拦截器应合并保留，业务调用也要真正使用这个实例；只新建它而继续调用另一个 axios.get()，不会改变原请求。

no-store 表示不使用 HTTP 缓存，不是一个纯粹关闭报错的空参数。先确认它符合接口的缓存要求。Workers 也支持 no-cache，但它的语义是要求重新验证，不能把两者当作随意互换的拼写。不要转而把所有请求改用 cf.cacheEverything，那是另一套缓存控制，会改变响应缓存范围。

有统一封装时，沿调用链检查 fetchOptions 有没有被覆盖。下面可以用于定位实际依赖：

npm ls axios

工作区和服务器产物可能解析到不同副本，不能只看顶层声明的版本范围。若由框架或其他库间接创建 Axios 实例，还要找到那个创建入口，而非只修改应用中不相关的配置。

网页正常，队列任务仍可能失败

框架有时会包装 Request 或 fetch，移除运行时不接受的选项。网页请求经过包装后正常，队列消费者和定时任务却可能使用原生 Request。反过来，未做这种包装的 Astro SSR 也可能直接命中故障。因此，问题不能限定成“只影响 cron”，也不能用浏览器里成功的一次调用证明 Worker 服务端已经恢复。

记录报错发生的处理入口、打包后的 Axios 版本及使用的 adapter。不要为排查打印认证头或业务正文；这次需要的证据是构造失败的错误文字和实际选项。

截至 2026 年 10 月 23 日核对的最新 Axios 正式发行仍为 1.20.0，不能仅因修复代码已合并或问题被关闭，就假定安装 1.20.1 已可用。显式采用受支持的 cache 值可以处理这里的兼容分支；回退旧版还会撤回其他修正，不宜作为默认处理。

部署后分别从原来的网页、队列或定时入口验收：确认请求不再在 Request 构造处失败，并核对上游收到的请求、HTTP 状态、业务结果和缓存行为。不要用会创建订单等写入的接口反复探测。若错误已经变成 DNS、TLS 或上游返回错误，应按新错误继续处理；那不再是 cache: 'default' 被拒绝的同一步。