as="fetch"预加载需配crossorigin="use-credentials"才发送cookie，且后续fetch()必须显式设credentials: 'include'，服务端须返回精确Access-Control-Allow-Origin和Access-Control-Allow-Credentials: true。
as="fetch"必须配crossorigin="use-credentials"才带 cookie
普通 fetch() 请求默认不带凭据（cookie），但 rel="preload" 的 as="fetch" 也遵循同一规则。如果你预加载的是受登录态保护的 JSON 接口（比如 /api/user.json），且后端依赖 cookie 鉴权，就必须显式声明 crossorigin="use-credentials"，否则请求发出去也没用——浏览器根本不会附带 cookie。
常见错误是只写 crossorigin（空值）或 crossorigin="anonymous"，这两种都等价于“不带凭据”，对需要 session 的接口无效。
-
crossorigin="use-credentials"是唯一能触发 cookie 发送的取值 - 服务端必须同步返回
Access-Control-Allow-Origin: https://your-domain.com（不能是*）和Access-Control-Allow-Credentials: true - 如果接口路径含查询参数（如
/api/data.json?lang=zh），href中必须完全一致，否则预加载缓存无法命中后续fetch()调用
as="fetch"预加载后，fetch()调用仍需手动指定 credentials
预加载只是提前下载资源，它不改变后续 JS 中 fetch() 的行为。即使你用 crossorigin="use-credentials" 预加载了 /api/config.json，在代码里调用 fetch('/api/config.json') 时，依然会按默认策略（credentials: 'same-origin'）发起请求——这在跨域场景下等于没带 cookie。
所以必须显式写：
立即学习“前端免费学习笔记（深入）”；
fetch('/api/config.json', { credentials: 'include' })
注意三点：
- 路径必须和
href完全一致（协议、域名、路径、查询参数） -
credentials: 'include'才对应crossorigin="use-credentials"；'same-origin'或'omit'都不会触发 cookie 发送 - 如果服务端响应头缺失
Access-Control-Allow-Credentials: true，fetch 会直接失败并抛TypeError: Failed to fetch，控制台可能只显示 CORS 错误，不提 cookie 事
as="fetch" + use-credentials 在字体或图片上基本没意义
as="fetch" 的设计初衷是为后续 fetch() 调用做准备，不是通用资源预加载手段。把它用在字体、图片、CSS 上属于误用：
- 字体必须用
as="font"+crossorigin（通常anonymous），as="fetch"不会触发 @font-face 加载逻辑 - 图片预加载应走
as="image"，as="fetch"虽然能下载，但不会进 image 缓存池，<img src>仍要重新拉一次 -
as="fetch"的 MIME 类型校验宽松，但浏览器不会为它建立专用缓存分区——它混在 general fetch 缓存里，复用率远低于专用类型
验证是否真带 cookie 的最简方法
别只看 Network 面板里有没有 cookie 字段，得确认请求头里实际发出的 Cookie 头：
- 打开 DevTools → Network → 找到预加载请求 → Headers 标签页 → 查看 Request Headers 下是否有
Cookie: xxx - 如果没有，检查两点：一是
<link>是否写了crossorigin="use-credentials"，二是 JS 里的fetch()是否加了{ credentials: 'include' } - 若请求头有
Cookie但响应 401，说明服务端鉴权失败，此时要查后端 session 是否过期，或SameSite属性是否设为Lax导致跨站被拦截
跨域凭证这事，前端配错一个字符，后端少回一个 header，整个链路就断在看不见的地方。宁可多查一遍请求头，也别靠“应该没问题”跳过验证。
