as="fetch"必须搭配明确mime类型和响应头，content-type与type属性须严格一致，且不支持credentials: "include"，url需字符串完全匹配，fetchpriority对其无效。
as="fetch"必须搭配明确的 MIME 类型和响应头
浏览器对 as="fetch" 的缓存复用，只认 Content-Type 响应头与 type 属性是否严格一致。写 <link rel="preload" href="/api/config.json" as="fetch" type="application/json">，但服务端返回 Content-Type: text/plain，预加载就白做——后续 fetch("/api/config.json") 仍会发新请求。
常见错误包括：
- 后端没设
Content-Type（如 Express 忘加res.set("Content-Type", "application/json")） - 构建工具或 CDN 自动改写响应头（比如把
application/json覆盖成text/plain） -
type写错格式，比如写成type="json"或type="text/json"，正确只能是application/json、application/ld+json等标准值
不能跨域或带凭据，否则 preload 失效
as="fetch" 预加载默认走 CORS 模式，但不支持 credentials: "include" 场景。如果你的 fetch() 调用带 credentials: "include"（比如需要 Cookie），那 <link rel="preload"> 就无法复用——浏览器会拒绝将预加载结果交给带凭据的 fetch 请求。
可行方案只有两个：
- 服务端改用 token header（如
Authorization: Bearer xxx），让 fetch 请求变成无凭据模式，再配as="fetch" - 放弃 preload，改用
fetch(..., { priority: "high" })（Chrome 111+ 支持），它不依赖预加载，但能提升调度优先级
preload 的 URL 必须和 fetch 调用的 URL 完全相等
浏览器判断是否复用预加载资源，用的是字符串精确匹配，不是语义等价。哪怕只差一个查询参数、大小写或末尾斜杠，都不会命中缓存。
典型翻车点：
- CSS 或 JS 中动态拼接 URL：
fetch(`/api/data?id=${id}`)，而 preload 写死为/api/data?id=123 - 服务端重定向：preload 指向
/config.json，但 Nginx 302 到/v2/config.json，浏览器认为这是两个资源 - 构建时注入哈希：
/api/config.abc123.json和/api/config.json并存，但没同步更新 preload 的 href
fetchpriority="high" 对 as="fetch" 无效
fetchpriority 只对 <img>、<script></script>、<link rel="stylesheet"> 等标签生效，<link rel="preload" as="fetch"> 加了 fetchpriority="high" 会被忽略，Network 面板里 Priority 仍是 Low 或 Medium。
真正影响调度的只有两件事：
- 是否在
早期声明（越靠前，越早进队列） - 是否满足上述 MIME、CORS、URL 三重一致性
复杂点在于：即使全部配对正确，若页面同时有大量 as="script" 或 as="font" 的高优 preload，fetch 类请求仍可能被挤到后面——它没有“Highest”档位，这点和 as="image" + fetchpriority="high" 不同。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
