Cache API仅能缓存成功GET响应（200–299），不支持POST/PUT等非幂等请求，且要求跨域资源配置CORS；适合缓存只读、无用户态的API（如新闻列表），需在fetch阶段按需存取并隔离命名管理。
网页应用不能直接用 Cache API 缓存任意 API 响应来实现“离线查看”，因为 Cache API 本身不支持缓存 POST、PUT 等非 GET 请求，也不缓存跨域且未配置 CORS 的响应，更不会自动保存用户登录态或动态生成的数据。它只缓存 成功返回的 GET 响应（status 200–299），且需由 Service Worker 主动拦截、判断、存取。所以关键不是“能不能缓存 API 数据”，而是“哪些 API 数据适合缓存、怎么安全可控地缓存”。
明确哪些 API 响应可以缓存
不是所有接口都适合放进 Cache API：
- 只读型接口：如文章列表、商品分类、天气预报（带合理过期时间）、静态配置项等，响应稳定、无用户身份强绑定
-
带版本或时间戳的接口：如
/api/news?version=20261008，内容固定，可按 URL 精确匹配缓存 -
响应头含 CORS 支持：服务端必须返回
Access-Control-Allow-Origin: *或指定域名，否则 cache.put() 会静默失败 - 避免缓存以下内容：登录态接口（/login）、支付回调、用户私有数据（/api/profile）、带 session cookie 的请求、POST 提交类请求
在 Service Worker 中缓存 API 响应的典型写法
不能靠 install 阶段预加载——API 数据是动态的，得在 fetch 阶段按需缓存：
- 先判断请求是否为需要缓存的 API，例如用 URL 匹配：
event.request.url.startsWith('/api/news') - 用
caches.match()查本地是否有缓存；有则直接返回 - 无缓存时调用
fetch()，拿到响应后用response.clone()分成两份：一份返回给页面，一份存入缓存 - 建议加简单 TTL 控制：比如在响应 headers 中写
X-Cache-TTL: 3600，读缓存前检查时间戳，超时则跳过缓存走网络
缓存命名与更新要隔离管理
API 缓存不能和静态资源混在一个缓存空间里，否则清理或升级时容易误删：
- 单独起名，如
'api-cache-v1'，便于独立维护 - 版本升级时，在 activate 阶段清理旧 API 缓存：
caches.keys().then(keys => Promise.all(keys.filter(k => k.startsWith('api-cache-')).map(k => caches.delete(k)))) - 避免用
cache.addAll()批量缓存 API 响应——它只接受 URL 字符串，无法传参或控制请求头，不适合动态接口
离线时如何返回合理内容
单纯缓存 API 响应还不够，用户断网刷新页面时需有兜底：
- 对关键接口返回缓存 + 状态标识，前端 JS 检查响应 headers 中是否有
X-From-Cache: true，提示“当前为离线数据” - 设置 fallback 页面：当缓存缺失且网络不可用时，
fetch()抛错，可在 catch 中返回一个预存的 offline HTML 页面或 JSON 结构（如{ error: "offline", data: [] }） - 不建议缓存整个用户主页 HTML——它通常含个性化内容，应使用 App Shell 架构：壳页面（shell.html）用 Cache-First，数据部分用 API 缓存+降级策略
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
