prefetch从不抢占当前页带宽，仅在window.onload后、主线程与网络空闲时低优先级加载；必须静态写入html、使用绝对或根相对路径、指定正确as值（如script/style），且响应需含cache-control: public。
prefetch 从不抢当前页带宽，但也不是“随便写就生效”
它根本不会和 preload、首屏 CSS/JS、<img> 争带宽——浏览器明确把它排在 window.onload 之后、主线程空闲、网络无高优请求时才发起。这意味着：你写了 <link rel="prefetch" href="/next.js" as="script">，只要页面还没 onload，Network 面板里就看不到任何请求。
常见误判是以为“没看到请求 = 代码错了”，其实更可能是：onload 被长任务卡住、图片加载慢、或用户刚点开就切走了。Chrome 默认过滤掉 prefetch 请求，必须手动勾选 Network 面板左上角的 “prefetch” 过滤器，再看 Priority 列是否为 Low。
as 属性写错，prefetch 就等于没写
as 不是可选项，它直接决定浏览器怎么解析响应、走哪条缓存路径、甚至发不发请求。漏写或写错，浏览器可能降级为 as="document"，对 JS/CSS 复用率暴跌；更糟的是静默失败——Network 里连条目都没有。
-
as="script"：用于预取 JS 文件，如/js/detail.4f9c.js -
as="document"：仅用于预取 HTML 页面（如/pages/checkout.html），但 Safari 支持极弱，慎用 -
as="style"：预取分离出的 CSS，不是内联<style></style> -
as="font"或as="fetch"：无效值，浏览器忽略，不报错也不请求
同源 + 静态写入 + 绝对/根相对路径，三者缺一不可
prefetch 只在 HTML 解析阶段被识别，动态用 JS 插入 <link> 基本无效——解析期已过，浏览器不认。路径也必须是绝对路径（https://example.com/js/next.js）或根相对路径（/js/next.js），./next.js 或 //cdn.example.com/next.js 都会解析失败。
跨域 prefetch 在 Firefox/Safari 中基本被无视，即使服务端开了 CORS 也没用。Webpack/Vite 构建时若未配 publicPath 或 base，很容易产出错误路径，导致 404。
和 preload 混用同一资源，等于白费带宽
同一个 URL 同时写了 preload 和 prefetch，Chrome 会发两次独立请求：一次 Highest 优先级进当前页专用缓存，一次 Low 优先级进 HTTP 缓存——两者不共享，也不复用。Network 面板能看到两个条目，Initiator 分别是 preload 和 prefetch。
真正该做的分层策略是：
- 首屏关键 JS/CSS/字体 → 用
<link rel="preload" as="">，必须带as和crossorigin（尤其字体） - 下一页确定要用的 JS/HTML → 用
<link rel="prefetch" as="">，静态写死在里 - 别对 API 接口（如
/api/user）写 prefetch —— 它不发fetch请求，只存二进制 blob
最常被忽略的一点：prefetch 的资源必须返回 Cache-Control: public, max-age=31536000，否则跳转后缓存失效，预取白做。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
