如何通过 Content Indexing API 引导用户在离线状态下访问已缓存内容-js教程-PHP中文网

Content Indexing API 仅声明可索引的离线内容，不管理缓存、不控制导航、不触发离线加载；其作用是将已缓存URL注册到浏览器离线界面，实际离线访问依赖Service Worker的fetch事件正确返回缓存响应。

如何通过 content indexing api 引导用户在离线状态下访问已缓存内容

Content Indexing API 无法引导用户访问离线缓存内容——它只负责向浏览器“声明”有哪些内容可被索引和展示，不参与缓存逻辑、不控制导航、也不触发离线加载。

Content Indexing API 的实际作用范围

这个 API 是浏览器提供给 PWA 的一个元数据注册接口，核心功能是让已缓存的页面（比如通过 Cache API 或 Workbox 缓存的 URL）在「网站设置 → 离线内容」或 Chrome 的 chrome://apps 等界面中显示为可发现项。它本身：

不读取、不写入、不验证缓存是否存在
不拦截网络请求，也不重写 fetch 事件
不与 Service Worker 的缓存策略自动联动
调用 registration.index.add() 成功 ≠ 内容已缓存，只是“挂了个名”

真正决定离线能否访问的是 Service Worker + Cache API

用户点击 Content Indexing 列表里的条目后，浏览器会发起一次标准导航请求（GET）。能否成功加载，完全取决于你的 Service Worker 是否在 fetch 事件中正确匹配并返回了缓存响应。常见疏漏包括：

缓存时用了带 hash 的文件名（如 main.a1b2c3.js），但 index.add() 注册的是未 hash 的路径（如 /app/），导致匹配失败
fetch 事件监听器未覆盖导航请求（缺少 event.request.mode === 'navigate' 判断）
缓存策略未包含 HTML 文件，或 HTML 缓存过期时间太短，离线时已失效
使用了 cache.match(event.request) 但没 fallback 到 networkFirst 或 cacheOnly 明确策略

如何让索引条目真正导向离线可用内容

必须手动对齐三件事：缓存行为、索引注册、导航响应。示例关键片段：

/* 在 Service Worker 中 */
self.addEventListener('fetch', event => {
  if (event.request.mode === 'navigate') {
    // 优先尝试匹配 HTML 缓存
    event.respondWith(
      caches.match(event.request)
        .then(resp => resp || fetch(event.request))
    );
  }
});
<p>// 缓存 HTML 页面（例如在 install 或 message 事件中）
caches.open('pages-v1').then(cache =>
cache.addAll(['/app/', '/app/article-123/', '/app/offline.html'])
);</p><p>// 索引注册必须与缓存路径严格一致
registration.index.add({
id: 'article-123',
url: '/app/article-123/',
title: '离线也能看的文章',
description: '已预缓存',
icons: [{ src: '/icons/icon-192.png', sizes: '192x192', type: 'image/png' }]
});</p>

注意：url 字段必须是完整相对路径（以 / 开头），且与 cache.addAll() 或 cache.put() 中使用的 key 完全一致（包括结尾斜杠、查询参数、大小写）。