rel="prefetch"对复杂页面跳转几乎没用，因其仅在onload后空闲时低优先级预取同源静态资源，依赖强缓存、精准as属性及用户行为可预测；写错或条件不满足即静默失效。
rel="prefetch" 对复杂页面跳转几乎没用，除非你清楚知道用户下一步点哪、资源路径静态、服务端配了强缓存，且页面 onload 稳定触发。
为什么写了 rel="prefetch" 却根本没发请求
不是代码写错了，而是浏览器压根没执行——它有三道硬门槛：
- 必须等
onload触发后才可能开始，如果用户 1 秒内就点了跳转链接，prefetch 请求直接被中止 - 目标 URL 必须同源（协议、域名、端口全一致），
/preview?id=abc123这种动态地址会被静默忽略 - 浏览器得处于“空闲”状态：没高优先级请求、CPU 和网络负载低；Chrome 甚至默认不显示 prefetch 请求，得手动在 Network 面板勾选
prefetch类型才能看到
as 属性写错或漏掉，等于白写
rel="prefetch" 必须带 as，否则浏览器无法判断资源类型，请求大概率被降级或丢弃：
- 预取 JS 文件必须写
as="script"，不能写as="fetch"或as="json"（浏览器根本不识别） - 预取 HTML 页面用
as="document"，预取 CSS 用as="style"，预取图片用as="image" - 别给字体写
as="font"——prefetch 不触发 CORS 预检，跨域字体静默失败
复杂页面跳转卡顿，真正该查的不是 prefetch
在线预览、多步骤表单、文档翻页这类场景，卡顿根源往往不在“资源没提前下”，而在“下了但没及时用”或“关键路径太长”：
立即学习“前端免费学习笔记（深入）”；
- 首屏是否用了
rel="preload"加载 LCP 图片、关键 CSS、字体？preload才是当前页的事 - 下一页资源是否真被缓存？检查服务端响应头有没有
Cache-Control: public, max-age=31536000，带临时 token 或 hash 的资源基本缓存不住 - 是否混用了
preload和prefetch？拿preload去预取下一页 JS，会抢首屏带宽，反而拖慢当前页
真正能起效的 prefetch，只出现在路径固定、行为可预测、缓存稳如磐石的少数环节——比如教程站点的 /lesson/1 → /lesson/2，其余多数“复杂跳转”场景，硬加 prefetch 只是让 HTML 更臃肿，Network 面板里连个请求影子都看不到。
