rel="preload"仅对本页立即渲染所需的资源生效，需严格匹配as和crossorigin属性；误用会抢占带宽、拖慢首屏。
link 标签的 rel="preload" 不是“写了就快”，用错反而拖慢首屏——它只对「当前导航立刻要用」的资源生效，且必须配对正确的 as 和 crossorigin。
什么时候该用 rel="preload"，而不是 rel="prefetch" 或 rel="preconnect"
三者语义和调度优先级完全不同，混用等于白写：
-
preload：浏览器高优先级下载，用于「本页马上渲染就要用」的资源（比如首屏字体、Hero 图、关键 CSS 中引用的 font-face） -
prefetch：低优先级后台加载，适用于「用户下一步可能访问的页面资源」（如点击后跳转页的 JS chunk），不保证执行时机 -
preconnect：仅建立跨域连接（DNS + TCP + TLS），不下载任何内容，适合 CDN 域名、第三方 API 域（如https://fonts.googleapis.com）
常见错误：把 main.js 写成 preload —— 它本身已被 defer 或 module 控制加载时机，再 preload 会抢占带宽，挤掉 HTML 或关键 CSS 的下载。
as 和 crossorigin 必须同时配对，否则资源不生效
浏览器靠 as 判断资源类型，从而分配正确优先级和解析逻辑；而 crossorigin 决定是否能读取响应体（尤其对 font 和 script）：
- 预加载字体：
—— 缺crossorigin，字体不会应用，控制台报 CORS 错误 - 预加载图片：
—— 无需crossorigin，但必须有as="image"，否则当普通 link 处理，失去高优先级 - 预加载脚本：
—— 若脚本来自同域，可省略crossorigin；跨域必须加，否则 fetch 失败
别在 CSS 里用 @import，也别用 preload 补救
@import 是串行阻塞式加载，实测拖慢 FCP 超 300ms。更糟的是，有人试图用 preload 提前拉 @import 的 CSS 文件——这毫无意义：
- 浏览器仍要等主 CSS 解析到
@import行才发起请求，preload无法绕过该解析时机 - 若预加载的 CSS 本身又含
@import，问题层层嵌套，白屏风险翻倍 - 正确做法：把所有关键样式内联进
，非关键 CSS 用media="print" onload="this.media='all'"延迟加载
preload 验证是否真正起效，只看 Chrome Network 面板的 Priority 列
光看资源是否出现在 Network 列表里没用，关键看调度优先级是否为 high：
- 打开 DevTools → Network → 刷新页面 → 找到预加载资源 → 检查
Priority列是否显示High - 若显示
Low或Medium，说明as值错误（比如漏写as="font"导致被当成fetch类型）、或路径 404、或服务器返回了no-cache等干扰头 - 注意：
preload资源不会在 Elements 面板中自动插入 DOM，它只是提前下载进内存/HTTP 缓存，后续由 CSS 或 JS 主动使用
最容易被忽略的一点：预加载资源必须被页面实际消费。如果 preload 了一个字体，但 CSS 里没用 @font-face 引用它，或者引用的 font-family 名不一致，这个预加载就完全浪费了带宽和解析开销。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
