link rel="prefetch"仅在当前页onload完成、浏览器空闲且页面未卸载时低优先级预取下页资源并存入http缓存，不加速首屏，需严格满足触发条件、同源、正确as属性（如as="script"）及静态写入head中，否则无效。
link rel="prefetch" 不是“加了就快”，它只在当前页 onload 完成、浏览器空闲、页面未卸载时，才低优先级地把资源塞进 HTTP 缓存——对首屏毫无帮助，用错反而拖慢真实请求。
prefetch 什么时候根本不会发请求
写了 <link rel="prefetch" href="/next.js"> 却没看到网络请求，大概率不是代码写错了，而是触发条件压根没满足：
- 当前页还没触发
onload（比如有长任务阻塞主线程、图片加载慢、JS 执行卡住） - 用户开了“节省流量”模式（Chrome / Edge 默认跳过 prefetch）
- 用的是 Safari —— 对非
script类型资源支持极弱，as="document"基本无效 - 页面很快被关闭或跳转（浏览器主动取消 prefetch 请求）
- 目标资源返回了
Cache-Control: no-store或max-age=0，浏览器连缓存都不想建，直接不发
验证是否发出请求：打开 Chrome DevTools → Network 面板 → 取消所有过滤器，或手动输入 prefetch 过滤；别只看 XHR 或 JS 标签页。
as 属性不是可选，写错等于白写
as 决定浏览器怎么处理这个请求：设什么 MIME、加什么 Accept 头、走哪条缓存路径。漏掉或写错，请求大概率降级为普通 fetch，甚至被忽略。
- 预取 JS 文件必须写
as="script"：<link rel="prefetch" href="/assets/detail.4f9c.js" as="script"> - 预取 HTML 页面必须写
as="document"：<link rel="prefetch" href="/pages/checkout.html" as="document"> - 预取 CSS 必须写
as="style"：<link rel="prefetch" href="/css/detail.css" as="style"> -
as="fetch"或as="json"是无效值，浏览器不识别，也不报错，只是当普通链接处理
注意：href 必须是合法路径（不能是 //cdn.example.com/xxx.js 这种协议相对地址），且必须同源（跨域 prefetch 在 Firefox/Safari 中基本被无视）。
prefetch 和 preload 别混着用同一资源
同一个 URL 同时写了 preload 和 prefetch，Chrome 会发两次请求——一次高优、一次低优，纯属浪费带宽和缓存空间。
- 首屏关键 JS/CSS/字体 → 用
<link rel="preload" as="...">，必须带as，且建议加crossorigin（尤其字体） - 下一页确定要用的 JS/HTML → 用
<link rel="prefetch" as="...">，放在里静态写死，别用 JS 动态插入 - 别对 API 接口（如
/api/user）写 prefetch —— 它不发 fetch 请求，也不解析响应体，只存二进制 blob
如果目标 HTML 是服务端渲染且含动态 nonce 或一次性 token，prefetch 缓存的 HTML 很可能因校验失败而无法渲染——这种页面根本不适合 prefetch。
真正要预取数据时，该换什么方案
prefetch 只存资源，不提供 JS 接口，也没法读取 JSON。想提前拿到 API 数据并供后续页面使用，得换路子：
- 页面加载完成后，用
fetch()+cache.put()存入 Cache API，后续通过cache.match()读取 - 在 SPA 路由切换前（比如用户点“下一步”按钮后、跳转前），主动
fetch()下一页所需数据 - 服务端启用 HTTP/3 QPACK 推送（需服务器支持，客户端兼容性有限）
-
rel="prerender"可整页预渲染，但只 Chromium 支持、内存开销大、不适用于数据动态生成的页面
最常被忽略的一点：prefetch 的收益高度依赖用户行为一致性。如果预取的页面路径随登录态、AB 实验、地域等动态变化，缓存命中率会断崖下跌——这时候不如关掉，别让浏览器白忙活。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
