cache.match 是 Cache 接口方法，用于在指定缓存中精确匹配请求的 URL、method 和 headers（含 query 参数顺序），返回第一个完全匹配的 Response；不支持模糊或前缀匹配，需在 Service Worker 上下文中调用且传入 Request 实例。
cache.match 是什么，它匹配什么
cache.match 是 Service Worker 中 Cache 接口提供的方法，用于根据传入的 Request 对象，在指定缓存中查找**完全匹配的缓存响应（Response）**。它不支持模糊匹配、正则或部分 URL 匹配，只做「请求 URL + method + headers（部分）」的精确比对。
常见误解是以为它能像路由一样“匹配路径前缀”，比如传入 new Request('/api/') 就命中所有 /api/* 请求——实际不会。它只匹配完整 URL 字符串（忽略 query 参数顺序？不一定，见下条）。
match 方法默认是否忽略 query 参数顺序
不忽略。Chrome、Firefox 均将 query 参数顺序视为匹配的一部分。例如：
await cache.match(new Request('https://a.com/data?id=1&name=test'))
只能匹配到缓存中 URL 完全为 https://a.com/data?id=1&name=test 的条目，而无法匹配 https://a.com/data?name=test&id=1，即使语义等价。
立即学习“前端免费学习笔记（深入）”；
解决办法是手动标准化 URL：
- 用
URL构造函数解析，再按 key 排序拼接 searchParams - 或直接在
cache.put()阶段就统一存储标准化后的 URL - 避免依赖
match处理非规范请求，优先在 fetch 事件中 normalize 再 match
如何正确调用 cache.match 获取响应
必须确保：缓存已打开、请求对象合法、且在 Service Worker 的上下文中执行（如 fetch 事件里）。常见错误包括：
- 在页面主线程直接调用
cache.match→ 报错cache is not defined - 传入字符串而非
Request实例 → 返回undefined（部分浏览器静默失败） - 未
await或未处理 Promise → 得到 pending 状态的 Promise 而非 Response - 缓存名写错，或缓存根本没
open过 →match返回undefined
正确示例：
self.addEventListener('fetch', event => {
event.respondWith(
caches.open('my-cache').then(cache =>
cache.match(event.request).then(response => {
return response || fetch(event.request);
})
)
);
});
match 和 matchAll 的关键区别
cache.match 只返回第一个完全匹配的 Response；cache.matchAll 返回匹配的所有 Response 数组（可用于多版本资源、带 vary header 的场景）。
但注意：matchAll 不会自动去重，也不按时间排序。如果你缓存了同一 URL 的多个变体（如带不同 Accept 或 Authorization header），matchAll 可能返回多个结果，需自行筛选。
性能上，match 更轻量；若只需一个响应（绝大多数 HTTP 请求场景），别用 matchAll 平白增加开销。
真正容易被忽略的是：match 不会触发缓存更新，也不会自动 fallback 到网络——它只是个查找操作。你得自己决定找不到时是 fetch、返回 stub，还是抛错。
