先说一个核心判断：prefetch 并非加速页面跳转的万能银弹。它的职责仅限于将静态资源提前存放进 HTTP 缓存，既不执行预渲染、不发起 API 请求，也无法保留用户输入的表单状态。当用户从商品列表页点击进入详情页时，link rel="prefetch" 能做到的，仅仅是提前下载 /product/123.js 和 /product/123.css 这两个静态文件——但页面挂载完成后，接口仍需重新请求，库存数据仍需实时校验，JavaScript 逻辑也照样从头执行。真正导致用户等待的关键瓶颈，它一个也解决不了。
那么，在实际转化链路中，哪些场景能让 prefetch 真正发挥作用？必须同时满足四个硬性条件：路径固定、资源为静态文件、用户点击概率高、且不涉及服务端动态生成的 nonce 或 token。
✅ 商品列表页可以对历史点击率排名前三的商品详情页 HTML 设置 as="document"，例如 。在此场景下，路径是写死的，资源是纯静态的，用户大概率会点击，完全符合 prefetch 的理想使用场景。
✅ 在订单提交流程中，如果“确认订单页”是纯静态模板，不包含 URL 查询参数、也不依赖客户端渲染，那么它的 JS 和 CSS 同样可以提前通过 prefetch 获取。
❌ 商品详情页如果包含动态参数就不可行——一旦 URL 携带了 ?utm_source=xxx 或 &token=abc，prefetch 的 href 就无法静态写死，等于无效。
❌ 含有服务端渲染 CSRF token 或一次性 nonce 的页面，缓存后校验会失败，资源虽然下载了却无法正常使用，严重时甚至可能触发安全拦截。
❌ 试图预取 /api/cart/add 这类接口地址同样没有意义。prefetch 根本不发送 fetch 请求，也不会解析响应体内容。
as 属性写错等于没写，而且容易引发降级
这个细节值得特别留意。浏览器依赖 as 属性来决定请求头、缓存分区以及 MIME 处理方式。一旦缺失或写错，请求大概率会被当作 as="document" 处理，甚至直接被静默忽略，连报错信息都不会出现。
- JS 文件必须使用
as="script"： - HTML 页面必须使用
as="document"： - CSS 必须使用
as="style"： as="fetch"、as="json"都是无效值，浏览器不会识别也不报错，只会当作普通链接处理。- 跨域资源（例如 CDN 上的 JS）在 Safari 和 Firefox 中基本会被忽略，即使写了
as也无法发起请求。
简单小结：as 属性的正确性直接决定 prefetch 是否生效。写错了，效果打折还是小事，更麻烦的是你很难排查问题所在。
动态注入比硬编码更可控，但有硬限制
将 link 直接硬塞进模板 head，等于让所有用户无差别下载一个可能永远用不到的资源——在移动端尤其敏感，流量和缓存空间都是稀缺资源。
不过在真实项目中，更推荐的做法是使用 IntersectionObserver 监听链接进入视口，或者更直接一些：在鼠标移入按钮时延迟 200 毫秒再触发注入 prefetchResource('/js/detail.js')。这样做的好处是只在用户真正可能点击时才开始预取，避免不必要的资源浪费。
但需要留意的是，动态插入的 link 在多数浏览器中不满足“HTML 解析时已存在于 DOM”这一条件，触发成功率远低于静态写法。Chrome 94 及以上版本会结合导航预测信号来提升 prefetch 触发率，但纯 JavaScript 注入无法获得这个信号的支持。
要验证 prefetch 是否生效，可以在 Network 面板手动筛选 prefetch 类型，观察 Initiator 是否为 prefetch，Priority 是否为 Low。跳转后，资源的状态码应为 200 (from memory cache) 或 304。
实际项目中最容易被忽视的一点是：你写的 prefetch 可能根本没有发起请求——不是因为代码写错了，而是用户刚打开页面就快速滑走了，或者 Chrome 还没来得及进入空闲状态。它连尝试都没开始过。这个问题需要在实践中留意，并提前考虑降级方案。
