Cache API 的 match 方法严格比对 Request 实例的 URL、method、headers 等字段，非模糊搜索；必须传入 Request 实例而非字符串 URL，且需确保缓存写入与读取时 Request 键完全一致。
Cache API 的 match 方法本身不“自动精准”，它的匹配精度完全取决于你传入的 Request 对象是否与缓存中存储的键一致。 它不是模糊搜索，而是严格比对——URL、method、headers（部分）、destination 等都参与匹配。想让它“精准”，关键在构造请求时就明确意图，而不是依赖 match 去猜。
匹配核心：Request 是钥匙，不是标签
Cache API 缓存的是 Request → Response 键值对。match 查找时，会用你传入的 Request 实例，逐字段比对缓存中已有的 Request 键。哪怕 URL 相同，但 method 不同（如 GET vs POST），或 headers 中有 cache-control: no-cache 这类影响语义的字段，match 就不会命中。
- 默认只比对 URL 和 method；若需更细粒度控制，创建缓存时要用
new Request(url, { ... })显式指定 headers、credentials 等 - 浏览器可能对某些 header 自动标准化（比如自动添加
accept），导致手动构造的 Request 与缓存键不一致，建议用 fetch 拦截到的原始 event.request 直接传给 match - 避免用字符串 URL 调用 match ——
caches.match('/app.js')是无效写法，必须传 Request 实例
常见失配原因及应对方式
很多“没命中”其实不是 match 有问题，而是缓存写入和读取时 Request 不统一。
-
带查询参数的 URL 变化：比如
/api/data?ts=123和/api/data?ts=456被视为两个不同请求。若想忽略时间戳等动态参数，可在 match 前规范化 URL：new Request(new URL(request.url).origin + new URL(request.url).pathname) -
CORS 请求的 credentials 差异：带
credentials: 'include'的请求，与不带 credentials 的同 URL 请求互不匹配。确保 install 阶段预缓存时使用的 Request 与 fetch 阶段拦截的 request 在 credentials、mode 等关键字段上一致 - POST 请求无法被 match：Cache API 不支持缓存 POST 响应（规范限制），match 对 POST 请求永远返回 undefined。这类请求应主动过滤，不进缓存逻辑
实战中提升匹配可靠性的做法
与其反复调试 match，不如从源头让缓存键更可控、更可预期。
- 在 install 阶段用
cache.addAll(['/', '/style.css', '/app.js'])预缓存时，内部会自动构造标准 GET Request，适合静态资源；若需自定义，统一用cache.put(new Request(url), response)显式控制 - fetch 事件中，直接使用
event.request调用cache.match(event.request)，避免二次构造造成偏差 - 对需要特殊匹配逻辑的资源（如图标按尺寸分类），可提前在 install 时用不同 cache 名（如
icons-small、icons-large）分组缓存，再按需 open 对应 cache 调用 match
验证匹配是否生效的简单方法
别只看最终结果，中间步骤可快速定位问题：
- 用
cache.keys()列出当前缓存的所有 Request 键，打印其url和method，和你要 match 的 request 对比 - 在 match 后加判断：
if (!response) console.log('Miss for:', request.url, 'cached keys count:', await cache.keys().then(keys => keys.length)) - 测试阶段可在 DevTools > Application > Cache Storage 中手动查看各 cache 下的实际键值，确认缓存写入是否符合预期
