preload只对浏览器发现太晚但首屏必需的资源生效；必须静态写在<head>最前（紧贴<meta charset>后）、as属性严格匹配类型（如字体需as="font"+crossorigin），否则无效或被忽略。
preload 不是加了就快，而是加对了才快——它只对浏览器“发现太晚但首屏立刻要用”的资源生效；加错位置、填错 as、漏掉 crossorigin，浏览器直接当普通请求处理，甚至完全忽略。
preload 必须写在 最前面，动态插入无效
浏览器只在 HTML 解析早期（parser 阶段）识别 link rel="preload"，一旦开始构建 DOM 或触发 DOMContentLoaded，再用 JS 插入就彻底失效。
- ✅ 正确位置：紧贴
<meta charset>后、<title>前，越靠前越好 - ❌ 错误做法：放在
<link rel="stylesheet">下方，或用document.createElement('link')在useEffect里插入 - ⚠️ 模板变量不解析：
href="/fonts/${family}.woff2"是纯文本，浏览器会按字面发起请求，结果 404
as 属性必须严格匹配资源类型，否则等于没写
as 不是可选提示，它决定请求头、CSP 校验、缓存分区和网络优先级。填错或漏写，Priority 列会显示 Low 或 Medium，而不是应有的 Highest（字体/JS）或 High（图片/CSS）。
- 字体（.woff2/.woff）→
as="font"+crossorigin（同源也必须加，否则 Chrome/Safari 直接丢弃） - CSS 文件 →
as="style"（不是"stylesheet"），后续<link rel="stylesheet">才能复用响应 - JS 脚本 →
as="script"；若含integrity，preload 也得带上，否则缓存不匹配 - 图片 →
as="image"；不支持srcset或sizes，只适合确定尺寸和格式的单图（如 Hero 区域背景图）
哪些资源真该用 preload，哪些绝对不该
浏览器默认只能发现 <img>、<script src>、<link rel="stylesheet"> 里的资源。以下几类被“藏”在 CSS 或 JS 里，解析完才暴露，才是 preload 的合理作用域：
立即学习“前端免费学习笔记（深入）”；
- ✅ 该加：CSS 中
@font-face引用的字体、内联<style>里的首屏background-image、<script type="module">紧跟的主 chunk（如app.js）、<picture>中关键<source>对应的 WebP - ❌ 禁用：懒加载图片（
loading="lazy"）、路由级异步 chunk（该用prefetch）、analytics.js、第三方 widget、API 接口 URL（HTTP 请求不可预加载） - ⚠️ 特别注意：不要对已用
<link rel="stylesheet">加 preload，否则触发二次解析，反而拖慢渲染
怎么验证 preload 是否真正起效
不能只看 HTML 里有没有那行代码。打开 Chrome DevTools → Network 面板，筛选目标资源，重点看三列：
-
Initiator：必须显示preload，不是parser或script -
Priority：字体/JS 应为Highest，图片/CSS 应为High -
Start Time：对比未加 preload 时同资源的起始时间，理想提前 200–600ms；若显示pending或canceled，可能是 HTTP/2 推送已发、或preconnect未就绪
最容易被忽略的是：preload 只下载不执行，仍需在 HTML 或 CSS 中正常声明资源（如 @font-face、<img src>），否则预加载结果不会被使用。
