rel="prefetch"仅下载资源不执行，rel="prerender"已废弃；当前唯一稳定方案是rel="prefetch"，需用绝对路径、避免查询参数、配合as="document"，但受网络/内存/浏览器限制可能失效，移动端Safari完全不支持。
link rel="prefetch" 和 rel="prerender" 的区别
浏览器对 rel="prefetch" 和 rel="prerender" 的处理逻辑完全不同，不能混用。前者只下载资源（HTML、JS、CSS），不执行；后者会完整加载并渲染目标页面（包括 JS 执行、DOM 构建、布局绘制），但仅在后台不可见标签页中进行。
目前 rel="prerender" 已被 Chrome 98+ 移除支持，Firefox 和 Safari 从未实现。实际能用的只有 rel="prefetch"（兼容性好）和较新的 rel="next"（语义化导航预取，部分浏览器支持）。
-
rel="prerender"现在基本等同于无效，Chrome 控制台会报Unknown attribute value "prerender" -
rel="prefetch"是当前唯一稳定可用的预加载手段，适用于用户大概率即将访问的页面（如分页第二页、登录后跳转页） - 若目标是“用户点击前就完成首屏渲染”，
rel="prerender"失效后，需改用服务端预渲染（SSR）或客户端懒 hydrate + 预取关键资源组合方案
如何正确写 link prefetch 关联目标页面
必须确保 <link> 标签出现在 <head> 中，且 href 是绝对路径或相对于当前文档的正确路径。相对路径容易出错——比如当前 URL 是 /user/profile，而 href="settings" 会被解析为 /user/settings，不是预期的 /user/profile/settings。
- 推荐使用绝对路径：
<link rel="prefetch" href="/account/settings.html"> - 避免带查询参数的 URL（如
?t=123），缓存策略可能失效；如有必要，请确保后端对这类参数做 cache-aware 处理 - 不要在动态生成的 HTML 中无条件插入大量
prefetch，会抢占主页面网络带宽和 CPU 资源 - 可通过
as="document"显式声明资源类型，帮助浏览器更早分配优先级：<link rel="prefetch" href="/checkout" as="document">
prefetch 在哪些场景下会失效或被忽略
浏览器有严格的启发式策略来决定是否真正发起 prefetch 请求，不是写了就一定加载。常见失效原因包括：网络条件差（如 2G 模式）、内存紧张、用户已开启省流模式、页面处于后台太久、或目标资源体积过大（Chrome 对单个 prefetch 有约 5MB 的隐式限制）。
立即学习“前端免费学习笔记（深入）”；
- 移动端 Safari 完全忽略
rel="prefetch"（iOS/iPadOS 一直未实现） - Chrome 会在页面 onload 后才开始 prefetch，所以首屏性能不受影响，但也意味着它无法加速“立即点击”的场景
- 如果目标页面返回 4xx/5xx 状态码，或响应头含
Cache-Control: no-store，prefetch 会静默失败，控制台无提示 - 跨域目标页面需满足 CORS，否则资源可下载但无法执行 JS（对 document 类型影响大）
替代方案：用 JavaScript 主动触发预加载更可控
当需要更高精度的时机控制（比如用户 hover 导航项时才开始）、或绕过浏览器 prefetch 启发式限制时，可以用 fetch() + document.implementation.createHTMLDocument() 或 Service Worker 缓存模拟 prerender 效果，但要注意副作用。
- 简单预取 HTML 内容：
fetch("/checkout", { credentials: "same-origin" }).then(r => r.text())，后续可注入到 iframe 或预解析 DOM - 配合
<iframe hidden>加载目标页（注意同源限制和隐私模式限制），能实现接近旧版 prerender 的效果，但开销更大、SEO 不友好 - 若使用 Webpack/Vite，可通过
import("/pages/checkout.js")预加载代码块，再结合路由懒加载，比纯 HTML prefetch 更贴近真实交互链路
真正要让“下一个页面秒开”，光靠 <link rel="prefetch"> 远不够——得看目标页自身是否轻量、是否有服务端渲染、关键资源是否内联、以及是否做了连接复用（HTTP/2 push 已淘汰，应依赖 preload + preconnect 组合）。
