如果你在搜索结果页尝试过使用 指令，却发现页面加载速度并没有明显改善——别急着怀疑自己的代码写错了。问题很可能不在于语法错误，而是这个预取指令根本没有被浏览器真正执行。
Prefetch 的触发条件相当“严苛”：它只会在浏览器空闲时，以低优先级的方式下载资源。而且，它对 URL 的要求非常严格——必须是静态的、带有强缓存头（例如 Cache-Control: public, max-age=31536000）、同源且路径合法。因此，如果你一开始就把搜索结果中前 10 条链接全部预取，那么很可能的结果就是：90% 的请求被浪费，缓存空间也被大量占用，得不偿失。
为什么搜索页面加 prefetch 常常无效
搜索结果页的典型流程很清晰：用户输入关键词 → 展示 10 条结果 → 点击第 1～2 条。但问题在于，浏览器并不会自动猜测用户究竟会点击哪一条；它只会识别你硬编码在 HTML 里的 href。看看常见的踩坑点：
- 用户尚未触发
load事件（例如 JS 渲染结果列表时用了长任务），prefetch 就被阻塞了 - 你预取了第 1～10 条链接，但实际点击集中在第 1 条，其余 9 个请求不仅白白浪费带宽，还挤占了缓存空间
- 搜索结果本身带有动态参数（如
/item?id=123&q=xxx），但你写的href是静态路径，二者无法匹配 - 后端返回的响应头没有配置
Cache-Control: public, max-age=31536000，等用户实际跳转时缓存已经失效，prefetch 等于白做
真正应该 prefetch 哪些搜索结果链接
正确的思路不是堆砌数量，而是只预取那些“确定会被高频点击、路径可静态化、资源复用率高”的 1～2 个目标。具体来说，可以从以下几个方向入手：
- 首页搜索框默认推荐的“热门商品”或“最近搜索”对应的结果页。例如
/product/iphone-15，这类 URL 是固定的 - 搜索页顶部的 banner 或“猜你喜欢”模块里的固定入口，像
/topic/summer-sale这样的路径 - 搜索关键词命中后，服务端已知的“首条高置信结果”。这可以通过 SSR 或构建时注入实现，而不是依赖客户端 JS 拼接
- 避免预取带有用户态参数的 URL（如
/search?from=history&uid=xxx），这类链接几乎无法复用，也不应该进入 HTTP 缓存
如何验证 prefetch 是否真的生效
光看 Network 面板里有没有请求是不够的，关键是要确认它是否真的进入了缓存，并且在跳转时被成功复用。正确的调试方法如下：
- 打开 Chrome DevTools → Network → Filter 输入
prefetch，勾选 “All”，找到Initiator: Other且Priority: low的条目 - 刷新页面后立即点开预取的目标页面，再回到 Network 面板，找到对应资源，观察
Size列是否显示from disk cache或from memory cache - 检查响应头：目标资源必须返回
Cache-Control，且不能包含no-store或private；如果包含immutable，那么 prefetch 后几乎可以做到永不重验 - 通过
chrome://net-internals/#events搜索URL_REQUEST和目标 URL，可以查看完整的生命周期，包括是否被取消、是否因为跨域被静默丢弃
容易被忽略的同源与路径细节
Prefetch 对路径和协议的敏感度极高，错一个字符就可能失效。
href必须是绝对路径，或者是相对于当前页面的合法路径。像//cdn.example.com/next.js这种协议相对 URL，会被浏览器当作非法协议直接忽略- 跨域请求（协议、域名、端口任意一项不同）在 Chrome/Firefox 中会被静默丢弃，连失败记录都不会出现在 Network 面板里
- 如果搜索页是 HTTPS，但预取的链接是 HTTP（例如
https://api.example.com/item/123），现代浏览器会直接跳过，不报错也不发送请求 - 在 SPA 场景下，不要在 JS 里动态插入
link标签（如document.head.appendChild(link)）。绝大多数浏览器只处理初始 HTML 解析阶段的 prefetch
其实最棘手的部分，不是怎么写代码，而是判断“用户下一步到底会点哪个”。这需要结合埋点数据、AB 实验和后端查询聚类来做决策，而不是靠前端硬编码去猜测。预取过多反而会污染缓存、拖慢真实请求，得不偿失。
