如何在缓存含CSRF令牌的请求时减小Service Worker缓存体积

这个问题我之前也碰到过，确实挺闹心——每次用户登出再登录，CSRF令牌一更新，之前缓存的资源就因为URL里的令牌参数变了失效，还要重新缓存一遍相同内容，缓存里全是冗余数据。给你几个实用的解决方案，按推荐程度排序：

1. 把CSRF令牌移到请求头（最推荐） #

这是最优雅的解决思路：把原本放在URL查询参数里的CSRF令牌，转移到请求头中。这样请求URL就固定不变，Service Worker的缓存key自然一致，不会出现重复缓存的问题，同时还能避免令牌出现在URL日志里的小安全隐患。

前端修改示例： #

// 从页面meta标签或Cookie中获取CSRF令牌
const csrfToken = document.querySelector('meta[name="csrf-token"]').content;

// 发起请求时把令牌放在请求头里，不再拼到URL上
fetch('/api/user/data', {
  method: 'GET',
  headers: {
    'X-CSRF-Token': csrfToken,
    'Accept': 'application/json'
  }
});

后端配合： #

需要调整后端的CSRF验证逻辑，允许从X-CSRF-Token（或你自定义的头部）中读取令牌进行校验，而不是只从URL参数里获取。大部分后端框架（比如Spring Boot、Django）都支持配置多来源的CSRF令牌读取。

2. 在Service Worker缓存时排除CSRF参数 #

如果暂时没法修改请求方式，也可以在Service Worker的fetch事件中，对请求URL做处理——移除CSRF令牌参数后再作为缓存key，这样不管令牌怎么变，相同资源都会匹配到同一个缓存条目。

Service Worker代码示例： #

self.addEventListener('fetch', (event) => {
  const request = event.request;
  
  // 只处理带CSRF参数的GET请求（根据你的实际参数名调整）
  if (request.method === 'GET' && request.url.includes('csrf_token')) {
    // 构造移除CSRF参数的新URL
    const url = new URL(request.url);
    url.searchParams.delete('csrf_token');
    const cleanedRequest = new Request(url.toString(), {
      method: request.method,
      headers: request.headers,
      mode: request.mode,
      credentials: request.credentials,
      cache: request.cache
    });

    // 优先从清理后的请求匹配缓存，没有则请求网络并缓存
    event.respondWith(
      caches.match(cleanedRequest)
        .then(cachedRes => {
          return cachedRes || fetch(cleanedRequest).then(networkRes => {
            caches.open('app-cache-v1').then(cache => {
              cache.put(cleanedRequest, networkRes.clone());
            });
            return networkRes;
          });
        })
    );
  } else {
    // 其他请求按原有逻辑处理
    event.respondWith(
      caches.match(request)
        .then(cachedRes => cachedRes || fetch(request))
    );
  }
});

这个方案不需要改动前端请求代码，只需要修改Service Worker逻辑，就能快速解决重复缓存问题。

3. 登录后主动清理旧缓存条目 #

如果上面两种方案都不适合，可以在用户登录成功后，通知Service Worker删除所有包含旧CSRF令牌的缓存条目。不过这个方案需要跟踪旧令牌，实现起来稍显繁琐，适合特殊场景。

前端登录成功后发消息： #

// 登录成功后，获取旧的CSRF令牌（需要提前保存）
const oldCsrfToken = localStorage.getItem('old-csrf-token');

if ('serviceWorker' in navigator && oldCsrfToken) {
  navigator.serviceWorker.controller.postMessage({
    type: 'CLEAR_OLD_CACHE',
    oldToken: oldCsrfToken
  });
  // 保存新令牌，下次登录用
  localStorage.setItem('old-csrf-token', newCsrfToken);
}

Service Worker监听消息并清理： #

self.addEventListener('message', (event) => {
  if (event.data.type === 'CLEAR_OLD_CACHE') {
    caches.open('app-cache-v1').then(cache => {
      cache.keys().then(keys => {
        keys.forEach(key => {
          // 删除包含旧令牌的缓存条目
          if (key.url.includes(`csrf_token=${event.data.oldToken}`)) {
            cache.delete(key);
          }
        });
      });
    });
  }
});

这个方案的缺点是如果令牌是完全随机的，可能会有遗漏的旧缓存条目，而且需要额外维护旧令牌的存储，不如前两个方案高效。

内容的提问来源于stack exchange，提问作者Ryan Griggs