prefetch 只在用户行为可预测且资源适中时生效，如分页第2页、登录跳首页等；需用绝对路径、指定as属性、避免动态URL，并注意与preload/preconnect的优先级冲突。
prefetch 用在哪些地方才真正生效
prefetch 不是“提前加载所有资源”的万能开关，它只对浏览器判断为“后续导航极可能用到”的资源起作用。典型有效场景包括：用户大概率会点击的下一个页面（如分页列表的第2页）、登录后跳转的首页、搜索建议下拉中高频命中的结果页。如果目标资源体积大（比如整页 HTML 超 500KB）、或用户行为路径不明确（比如首页上十几个随机推荐链接），prefetch 很可能被浏览器忽略或延迟执行。
怎么写 link rel="prefetch" 才不白写
关键不是加了标签就完事，得让浏览器能识别意图并调度资源：
- 必须用
<link rel="prefetch" href="/next-page.html" as="document">，as属性不能省——告诉浏览器这是 HTML 文档，否则默认按fetch处理，可能进错缓存队列 - href 必须是绝对路径或根相对路径（如
/static/js/chunk-abc.js），相对路径（./page2.html）在某些上下文中解析失败 - 避免 prefetch 动态生成的 URL（如带时间戳或用户 ID 的地址），浏览器无法预判，大概率跳过
- 不要在
<head>末尾堆砌一堆 prefetch，优先级会被稀释；建议只放 1–3 个最高置信度的目标
为什么 Chrome 控制台看不到 prefetch 请求
这是正常现象。prefetch 请求不会出现在 Network 面板的“All” 或 “Doc” 分类里，它走的是独立的预连接通道，仅在“Prefetch cache”或通过 chrome://net-internals/#events 查看（筛选 URL_REQUEST_PREFETCH 类型）。更可靠的验证方式是：
- 打开 DevTools → Application → Cache Storage，检查是否有对应 URL 的缓存条目（注意：不是 Memory Cache 或 HTTP Cache）
- 在目标页面首次加载时，观察 Network 面板中该资源的
Size列是否显示from Prefetch Cache - 若没看到，说明浏览器判定当前带宽/电池/内存不足，主动丢弃了 prefetch——这种策略不可控，别硬扛
prefetch 和 preload、preconnect 混用时的坑
三者共存时，浏览器按优先级排序：preload > preconnect > prefetch。常见翻车点：
立即学习“前端免费学习笔记（深入）”；
- 对同一资源同时写了
preload和prefetch，后者直接被无视——preload已强制加载，再 prefetch 是冗余操作 - 用
preconnect连接 CDN 域名后，又prefetch该域名下的资源，看似合理，但若 CDN 返回Cache-Control: no-store，prefetch 缓存失效，白忙一场 -
prefetch的as值写错（比如把 JS 写成as="script"），Chrome 会静默降级为as="fetch"，导致无法进入文档级缓存，后续导航仍要重新下载
真正起效的 prefetch 很少，依赖用户行为模式、资源大小、当前设备状态三者耦合。与其堆数量，不如盯住那一个最确定的下一步。
