静态写死 基本不可用：safari 旧版忽略、chrome 请求可能不显示、服务端 nonce/token 导致缓存失效；应改用 hover/可视区触发+动态注入，或直接 import() 预取代码分割模块。
直接写 <link rel="prefetch" href="/next-page.html"> 是错的——它会在用户根本没打算点进去时就消耗流量，Safari 旧版不认，Chrome 可能发了请求却在 Network 面板里找不到，而且预取整个 HTML 容易因服务端 nonce/token 失效导致缓存后白加载。
为什么静态写死 prefetch 基本不可用
浏览器对 rel="prefetch" 的执行非常保守：页面还没触发 onload 就不会发起请求；用户切走或刷新标签页，请求仍可能在后台继续下载；Safari 在 iOS 16.4 之前基本忽略它，尤其对 as="document" 类型；更麻烦的是，它不报 JS 错误，失败只体现在 Network 面板里状态码为 404 或 net::ERR_FAILED，但你很难第一时间发现。
- 硬写
href="/next-page.html"会连带拉取该 HTML 中所有<script></script>、<link rel="stylesheet">、图片等资源，实际流量远超预期 -
as="document"不推荐：服务端动态插入的<script nonce="xxx"></script>会导致缓存后的 HTML 执行失败 - 路径必须是绝对路径或相对于当前 HTML 的合法 URL，
//cdn.example.com/xxx.js这种协议相对路径会被当成非法协议而静默忽略 - 返回头必须含
Cache-Control: public, max-age=31536000，否则下次跳转时缓存失效，prefetch 白做
hover 或可视区触发 + 动态注入 link 标签
这才是真正可控的做法：用户有明确意图（悬停卡片、滚动到某模块），才创建并插入 <link rel="prefetch">。它绕开了静态写死的所有缺陷，且兼容性更好。
- 用
document.createElement('link')创建，显式设置rel="prefetch"和as="script"（别用as="document"） - 触发时机加 200ms 延迟，避免误触；但别超过 300ms，否则失去预取意义
- 只预取确定的 chunk 路径，比如 Vite 构建后生成的
/assets/DetailPage.xxxx.js，不是/detail这种路由地址 - 如果对应 CSS 是分离的（如
DetailPage.xxxx.css），记得一并 prefetch；字体优先用preload，不是 prefetch - React/Vue 中放在
useEffect或onMounted里执行，避免 SSR 渲染时报错
用 import() 替代 prefetch 更简单可靠
如果你的“下一页”是代码分割后的模块（比如 React 的 lazy(() => import('./DetailPage'))），直接调用这个 import() 表达式就行。浏览器会自动预取对应 chunk，本质是 runtime prefetch，优先级略高于 rel="prefetch"，且所有现代浏览器都支持。
- 不用手动管理
<link>标签的创建和销毁 - 天然规避跨域、路径解析、缓存头等问题
- 失败可 catch，成功后模块立即可用，不需要再手动
eval或appendChild - 适合配合 Suspense 或 loading 状态做体验优化，比如悬停时开始
import()，点击时直接render
prefetch 不解决首屏慢，也别和 preload 混用同一资源
prefetch 是给“下一页”准备的，不是给“当前页”加速的。它在 onload 后空闲时才低优先级发起，对 LCP、FCP 完全没帮助。首屏关键图、字体、核心 JS 必须用 preload，且要配 as 属性和 crossorigin（字体）或 fetchpriority="high"（图片）。
- 既
preload又prefetch同一个main.js，Chrome 会发两次请求 - prefetch 的资源若未被后续导航使用，会一直躺在 HTTP 缓存里，占用空间还可能污染缓存
- 验证是否生效，不能只看 Network 面板有没有请求，得确认跳转后该资源是否从 memory cache 或 disk cache 加载（Size 列显示
from cache）
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
