preload请求因Authorization头缺失无法复用缓存的技术咨询

我为网站添加了如下preload配置：

<link rel=preload href=http://api.github.com/... as=fetch crossorigin=anonymous>

后续会通过fetch()调用该资源，起初运行正常，预加载请求会在页面加载初期发送至远程服务器并成功获取响应。

之后因业务需求，我为fetch()调用添加了Authorization: Bearer ...请求头，这导致预加载请求与后续fetch请求的HTTP头不匹配，预加载结果无法被复用（Chrome与Firefox均已提示该问题）。

我也曾尝试在主页面响应中通过Link HTTP头添加预加载配置，但问题仍未解决。

目前的困境是：我无法为预加载请求添加相同的Authorization头，导致两次请求始终不匹配，预加载失去作用。

现咨询以下问题：

1. 是否可以为preload请求添加Authorization: Bearer ...头？
2. 是否可以让浏览器忽略两次请求的头差异？
3. 有没有其他可行的解决方案？

问题解答 #

1. 能否为preload请求添加Authorization头？
   不行。不管是用<link rel="preload">标签还是HTTP的Link头，都没有直接设置自定义请求头的方式。浏览器发起preload请求时只会携带默认头信息，没法手动注入Authorization这类自定义头。

2. 能否让浏览器忽略两次请求的头差异？
   也不行。浏览器判断资源是否可复用的核心规则里，请求头匹配是硬性条件——只要头信息不一致，就会判定为不同请求，不会复用预加载资源，没有开关能跳过这个检查。

3. 其他可行解决方案

• 延后预加载时机：等拿到Authorization令牌后，用JavaScript手动发起预加载请求（替代标签式预加载）。比如直接用fetch带令牌请求目标资源并配置缓存，这样后续的fetch请求就能复用缓存结果：

  // 假设已获取到token
  fetch('http://api.github.com/...', {
    headers: { 'Authorization': 'Bearer ...' },
    cache: 'force-cache'
  });
  

• 借助Service Worker统一处理请求头：注册Service Worker，拦截所有目标资源的请求，在Worker中统一为请求添加Authorization头。这样预加载和后续fetch请求的头信息会保持一致，浏览器就能正常复用资源。不过这种方案需要额外维护Service Worker逻辑，复杂度稍高。
• 协调后端调整接口策略：如果业务允许，让目标API在无Authorization头时返回基础数据，带令牌请求返回完整数据。但这种方案需要后端配合修改接口逻辑，需结合业务场景评估可行性。

内容的提问来源于stack exchange，提问作者Balázs Árva