rel="preload"仅对当前页面有效，因其目标是“当前页马上要用”的资源，页面跳转后预加载即终止或丢弃，且缓存不跨会话复用；跨页面预加载必须用rel="prefetch"（低优先级空闲时下载）或rel="preconnect"（提前建立连接）。
跨页面资源预加载不能用 rel="preload"，该属性只对当前页有效；必须改用 rel="prefetch" 或 rel="preconnect"，否则浏览器根本不会拉取。
为什么 rel="preload" 对跨页面无效
它只告诉浏览器“这个资源当前页马上要用”，一旦页面跳转，预加载就终止或被丢弃。Chrome Network 面板里能看到 prefetch 请求的 Initiator 是 prefetch，而 preload 的 Initiator 是 preload 且仅存在于当前页生命周期内。
-
preload资源进的是当前页的 script/font/image 缓存池，不跨会话复用 - 即使资源路径相同，
preload在 A 页面写，B 页面也拿不到缓存命中（除非 B 页面自己也声明） - 滥用
preload做跨页预载，还会抢占首屏带宽，拖慢当前页渲染
rel="prefetch" 才是跨页面预加载的正确选择
它明确指示浏览器：“这个资源用户**可能**在下一次导航中需要，请在空闲时低优先级下载”。浏览器通常在主页面加载完成、CPU/网络空闲后才发起请求。
- 适用于：下一屏 HTML（
href="product.html"）、关键 CSS/JS（as="style"或as="script"）、静态资源（如通用组件 JS） - 不适用于：字体、首屏图、关键 CSS——这些属于当前页，用
preload更合适 - 注意：不要在
prefetch中写as="font"，字体需同域或显式crossorigin，而 prefetch 不触发 CORS 预检，容易静默失败 - 路径必须为绝对或根相对（如
/js/next-page.js），避免子路径下解析错误
rel="preconnect" 配合 prefetch 提前建连第三方域名
如果下一页要从 CDN 或 API 域名加载资源，prefetch 前先 preconnect，能省掉 DNS + TCP + TLS 的 300ms+ 延迟。
- 示例：
<link rel="preconnect" href="https://cdn.example.com" crossorigin> - 务必加
crossorigin，Safari 和部分旧版 Chrome 否则忽略 - 不要超过 4–6 个，浏览器并发连接数有限，多连反而挤占主站资源
- 不要在
preconnect后立即发请求，建议间隔至少 100ms，确保连接真正就绪
验证是否真起作用的三个关键点
别只看代码写了没，得看 Network 面板里实际行为：
- 筛选
prefetch请求，确认Initiator列显示为prefetch，不是parser或script - 检查
Priority应为Low，若出现Highest说明误用了preload - 跳转到下一页后，目标资源应直接从内存/HTTP 缓存加载，Network 面板中状态码为
200 (from memory cache)或304
最容易被忽略的是：prefetch 资源若未被后续页面实际引用（比如路径拼错、HTML 里没 <script src></script> 或 <link rel="stylesheet">），浏览器会在 DevTools Console 里报 Resource was preloaded using rel="prefetch" but not used within a few seconds —— 这不是警告，是明确失效信号。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
