link rel="prefetch" 是低优先级、空闲时预取下一页资源的机制，非当前页加载工具；它不执行、不解析、不提供数据接口，且受 onload、同源、空闲状态等硬性条件限制，失败常因触发条件未满足而非代码错误。
link rel="prefetch" 不是“预加载当前页资源”的工具，它只在页面 onload 后、浏览器空闲时，低优先级下载下一页可能用到的资源并存入 HTTP 缓存——写对了也不保证执行，写错了基本没反应。
为什么写了 link rel="prefetch" 却看不到 Network 请求
常见原因不是代码写错，而是触发条件没满足：
- Chrome 默认不显示
prefetch请求，需在 DevTools Network 面板勾选prefetch类型，或清空所有过滤器 - 资源已被强缓存（如
Cache-Control: immutable），浏览器直接从磁盘读，根本不会发新请求 - 页面还没完成 onload，或用户已跳转/关闭标签页，prefetch 被中止
- URL 跨域（协议、域名、端口任一不同），浏览器静默忽略，不报错也不请求
-
as属性缺失或错误（比如写成as="fetch"），导致降级为as="document"甚至被忽略
link rel="prefetch" 必须满足的三个硬性条件
缺一不可，否则等于白写：
- 必须放在
<head>中，且 HTML 解析时已存在 DOM —— 动态插入（如document.head.appendChild(link)）大多无效 - 目标 URL 必须同源，跨域请求不会发起（连 OPTIONS 都没有）
- 浏览器必须处于空闲状态：无高优先级请求、CPU/网络负载低、页面未卸载
典型正确写法：<link rel="prefetch" href="/js/detail.chunk.js" as="script">；as 值必须准确对应资源类型（script、style、document、image 等），不能乱填。
立即学习“前端免费学习笔记（深入）”；
和 preload 混用会重复请求
同一个资源如果同时被 preload 和 prefetch 声明，Chrome 会发两次独立请求：
-
preload是高优先级、立即 fetch、用于当前页 -
prefetch是低优先级、空闲时 fetch、用于下一页 - 浏览器不合并，也不去重，Network 面板里能看到两个不同
Initiator的条目
尤其注意构建工具（如 Webpack 的 SplitChunksPlugin + prefetch: true）自动生成的 prefetch，容易和你手动加的 preload 冲突。验证方式很简单：打开 DevTools Network，看同一 URL 是否出现两次，Priority 分别标为 high 和 low。
真正想“预取数据”，prefetch 不适用
link rel="prefetch" 只下载、不执行、不解析、不提供 JS 接口——它不会触发 API、不运行脚本、不吐出 JSON 给你用。
- 要提前获取可读取的 API 数据，该用
fetch()+cache.put()存入 Cache API - 关键接口可在路由切换前主动
fetch，配合 Suspense 或 loading 状态管理 - 如果是代码分割模块（如 React 的
lazy(() => import('./Page'))），直接调用import('./Page')更简单可靠，浏览器自动按需 prefetch chunk
最常被忽略的一点：prefetch 的“空闲”是浏览器定义的，不是你定义的。用户开省流模式、用 2G 网络、内存紧张，或者刚进页面就猛划屏幕，prefetch 就会被跳过——它天生不可靠，只适合锦上添花，不能作为数据加载链路的一环。
