prefetch仅适用于用户下一步大概率访问且路径确定的静态资源，如SPA首页预取用户中心页JS、电商列表页预取高点击率商品页资源；不适用于API接口、低点击率页面、含动态token的HTML及首屏优化。
prefetch 适合什么场景，不适合什么场景
它只对「用户下一步大概率会访问、且资源路径完全确定」的页面片段有效，不是通用加速方案。
适合的典型场景：
- SPA 首页预取用户中心页的
user-center.abc123.js（构建后固定路径） - 电商列表页预取点击率 Top 3 商品详情页的 JS + CSS chunk（如
/assets/DetailPage.xxxx.js和/assets/DetailPage.xxxx.css） - 表单多步流程中，当前页已知下一步必为
/step2.html，且该页静态 HTML 不含动态 nonce/token
明确不适合的场景：
- 预取
/api/user这类接口——prefetch不发fetch请求，也不解析响应体，只存二进制 blob，毫无意义 - 预取用户 90% 不会点的二级菜单页——纯带宽浪费，移动端尤其伤
- 预取带服务端动态渲染的 HTML（如含随机
nonce或登录态 token 的/profile）——缓存后复用时 nonce 失效，白加载还报错 - 用在首屏性能优化上——它等
onload完才启动，对 LCP/FCP 零帮助
为什么写了 link rel="prefetch" 却没看到网络请求
这不是代码写错了，而是浏览器压根没满足触发条件。常见真实原因：
立即学习“前端免费学习笔记（深入）”；
- 当前页还没触发
onload：长任务卡主线程、大图未加载完、JS 执行阻塞，prefetch 就不会启动 - 用户开了“节省流量”模式（Chrome/Edge 默认跳过 prefetch）
- 用的是 Safari —— iOS 16.4 之前对
as="document"基本无视，as="script"支持也弱 - 页面快速跳转或关闭：浏览器主动取消 prefetch，哪怕请求已发出
- 目标资源返回
Cache-Control: no-store或max-age=0：浏览器连缓存都不建，直接不发请求
验证是否发出请求：打开 Chrome DevTools → Network 面板 → 清空所有过滤器（别只看 XHR），或手动输入 prefetch 过滤。
动态注入 link rel="prefetch" 比静态写死更可控
静态写在 <head> 里等于“一锤定音”，用户还没动就开下，不可退、不可测、不省流。动态注入才能匹配真实意图：
- 触发时机选
mouseenter（加 200ms 防误触）或IntersectionObserver（元素进入可视区） - 必须显式设置
as：预取 JS 写as="script"，CSS 写as="style"，HTML 写as="document"（但风险高，慎用） -
href必须是绝对路径或根相对路径（如/assets/DetailPage.abcd.js），避免./next.js在嵌套路由下解析错 - React 中放在
useEffect，Vue 中放在onMounted，避免 SSR 渲染时报错
示例代码：
const prefetchResource = (url) => {
const link = document.createElement('link');
link.rel = 'prefetch';
link.as = 'script';
link.href = url;
document.head.appendChild(link);
};
card.addEventListener('mouseenter', () => {
setTimeout(() => prefetchResource('/assets/DetailPage.abcd.js'), 200);
});
比 prefetch 更简单可靠的替代方案是 import()
如果你的“下一页”已是代码分割模块（如 React 的 lazy(() => import('./About'))），直接调用这个 import() 表达式就行。
优势明显：
- 浏览器自动发起 runtime prefetch，优先级略高于
rel="prefetch" - 天然兼容所有现代浏览器，不用操心
as、crossorigin、路径拼接 - 不需要知道构建后的真实文件名，Webpack/Vite 会自动映射
- 不依赖
onload或浏览器空闲状态，时机更可控
注意：import() 只适用于 JS 模块，不能替代预取 HTML 或字体；字体仍建议用 <link rel="preload" as="font">。
