preload必须紧贴<meta charset>后、<title>前，且as属性严格匹配资源类型并配齐crossorigin等要求，否则浏览器降级为普通请求；仅适用于CSS或JS中“藏”着的首屏必需资源，如@font-face字体、内联样式背景图等。
preload必须紧贴后，不能插在任何标签中间
浏览器只在 HTML 解析器（parser）刚启动、还没构建 DOM 时识别 rel="preload"，一旦遇到 <title> 或 <link rel="stylesheet"> 就可能错过。动态插入（比如 document.createElement('link')）完全无效，连 Network 面板都看不到请求。
常见错误包括：
- 把
<link rel="preload">放在<meta charset>和<title>中间，但前面插了个<meta name="viewport">—— 实际已晚于最佳时机 - 用模板引擎生成 HTML 时，
<link rel="preload">被渲染在<link rel="stylesheet">后面，导致首屏字体加载延迟 200ms+ - 在 SSR 框架里误以为“服务端吐出就一定早”，结果因模板结构混乱，实际写入位置靠后
as属性写错或漏写，等于没加 preload
as 不是可选提示，它直接决定浏览器是否启用对应资源的高优先级通道、CORS 策略、缓存分区和解码行为。填错或不填，Network 面板里 Priority 列会显示 Low，Initiator 是 (Other) 而不是 preload。
关键匹配规则：
立即学习“前端免费学习笔记（深入）”；
- 字体文件（.woff2/.woff）→ 必须
as="font"+crossorigin（同源也得加，Chrome 120+ 默认强制 CORS） - CSS 文件 →
as="style"（不是"stylesheet"），且需配onload="this.onload=null;this.rel='stylesheet'"才能自动转为样式表 - JS 脚本 →
as="script"；若原<script>有integrity，preload 也必须带相同值，否则缓存不复用 - 图片 →
as="image"；不支持srcset或sizes，只适合确定尺寸/格式的单图（如 Hero 区域背景图）
静态发布时，模板变量和路径容易导致 404
预加载是纯静态解析阶段的行为，所有 href 值在 HTML 输出时就必须是真实可访问的 URL。模板语法如 /fonts/${family}.woff2 或 ./images/logo.png 在浏览器里会被当字面量处理，不经过 JS 运行时解析。
实操要点：
- 相对路径要以 HTML 文件所在位置为基准，推荐统一用根相对路径（
/assets/fonts/inter.woff2）或绝对 URL - 构建工具（如 Webpack/Vite）输出的哈希文件名，必须在模板中同步替换，不能靠运行时拼接
- CI/CD 流水线中，检查生成的 HTML 是否含
href404 的preload标签（可用正则扫描 + HEAD 请求验证）
别对已声明的 CSS/JS 重复 preload
对同一个 URL 既写 <link rel="preload" as="style"> 又写 <link rel="stylesheet"> 是安全的，但若 preload 的 href 和后续 rel="stylesheet" 不完全一致（差一个查询参数、协议、大小写），浏览器会当作两个资源，触发二次下载。
更危险的是：
- 对
<script src="app.js">preload，但脚本里又动态 import() 同一文件 —— 可能因缓存键不一致，导致重复 fetch - 把路由级异步 chunk（如
detail.js）误用 preload，它会抢占当前页带宽，拖慢 LCP - 给
loading="lazy"的图片加 preload，逻辑矛盾：一个是推迟加载，一个是提前拉取
真正该用 preload 的，只有那些被“藏”在 CSS 或 JS 里、浏览器解析完才暴露的资源：比如 @font-face 引用的字体、内联 <style> 里的 background-image、<script type="module"> 后紧跟的主 chunk。
