rel="prefetch"仅在浏览器空闲且低优先级带宽可用时触发，适用于同源可预测后续页面的文档等可缓存资源，需指定as属性和正确路径，chrome/edge支持较好而safari更保守。
HTML rel="prefetch" 什么时候真正起作用
它只在浏览器空闲、低优先级带宽可用时才加载，不是“立刻取”。很多开发者以为加了就一定能提前拿到资源，结果首屏没变化，后续跳转也没变快——大概率是触发条件没满足。
- 必须是用户可能访问的后续页面（比如分页链接、下一步表单页），且路径明确可预测
- 目标资源需同源，跨域需配
crossorigin属性，否则静默失败 - Chrome 和 Edge 支持较好；Safari 对
prefetch的调度更保守，有时压根不发请求 - 不要对
/api/xxx这类接口用prefetch，它只适用于文档、脚本、样式等可缓存资源
<link rel="prefetch"> 的写法和常见错误
最常错的是把 URL 写成相对路径但没考虑当前页面位置，或者漏掉 as 提示类型，导致浏览器无法正确设置请求头或缓存策略。
- 必须指定
href，且建议用绝对路径或根相对路径（如/page2.html），避免./next.html在嵌套路由下解析错 - 强烈建议加上
as="document"，否则默认按as="fetch"处理，可能被降权甚至忽略 - 别在
里放，必须在中，否则多数浏览器不识别 - 错误示例：
<link rel="prefetch" href="next.html">→ 缺as，路径易错，无 crossorigin 跨域支持 - 正确示例：
<link rel="prefetch" href="/pages/step2.html" as="document" crossorigin>
prefetch 和 preload、prerender 的关键区别
三者常被混用，但行为完全不同：preload 是“现在就要”，prefetch 是“以后可能要”，prerender 是“干脆把整个页面渲染好藏起来”——后者已被 Chrome 废弃，别再用。
-
preload：强制高优先级加载，用于当前页马上要用的资源（如首屏字体、关键 JS），会阻塞 DOM 解析 -
prefetch：低优先级后台加载，不影响当前页性能，适合用户操作后才出现的资源 -
prerender：已从 Chromium 移除，Safari 也不支持，rel="prerender"现在只是个无效字符串 - 别用
prefetch替代懒加载图片或组件，它不触发执行，只存到 HTTP 缓存里
怎么验证 prefetch 是否生效
不能只看 Network 面板有没有请求，得确认它是否进了缓存、并在后续导航中被复用。很多情况下请求发了，但因为缓存策略或 MIME 类型不匹配，实际没用上。
立即学习“前端免费学习笔记（深入）”；
- 在 Chrome DevTools 的 Network 标签页，筛选
Initiator列为Prefetch的请求 - 点开该请求，检查 Response Headers 中是否有
X-Content-Type-Options: nosniff或Content-Type不是text/html（文档类需匹配） - 跳转到目标页面后，在 Network 面板刷新，看该 HTML 是否显示
from disk cache或from memory cache - 如果看到
from service worker，说明你的 SW 拦截了，prefetch 可能被绕过
as="document" 和跨域配置。没这两项，prefetch 很可能只是安静地失败，连控制台警告都没有。 
