as属性必须写对，因为浏览器依赖它决定资源优先级、缓存策略和mime处理逻辑；漏写或错写会导致preload静默失效，降级为低优先级fetch，字体等关键资源无法复用或加载失败。
preload 的 as 属性为什么必须写对
浏览器靠 as 值决定资源优先级、缓存策略和 MIME 处理方式。写错或漏掉，等于告诉浏览器“我不知道这是啥”，它就按最低优先级下载，甚至不进字体加载流程。
-
as="font"必须搭配crossorigin和type="font/woff2"，否则 Chrome 直接忽略预加载，后续仍发一次请求 -
as="style"才能让预加载的 CSS 被后续<link rel="stylesheet">复用；写成as="fetch"或空着，资源进缓存但不参与样式解析，DevTools 会标 “preload was not used” -
as="script"配合动态import()有效；但若 JS 是同步加载（没加async/defer），preload 反而抢带宽，拖慢 HTML 解析
preload 和 prefetch 混用时最常踩的坑
二者语义完全不同：preload 是“现在就要”，prefetch 是“可能以后要”。混用不是功能失效，而是资源调度逻辑彻底错乱。
- 把首屏字体写成
<link rel="prefetch" href="Lato.woff2" as="font">→ 浏览器当低优先级处理，FOIT 时间拉长，文本闪白 - 把后台管理页的 JS 用
preload→ 占用 HTTP/2 stream，挤掉当前页的critical.css下载，首屏渲染延迟 - 同一资源既 preload 又 prefetch → 浏览器可能发起两次请求，或因优先级冲突导致其中一次被 cancel
怎么验证 preload 是否真起作用
光加标签没用，关键看 Network 面板里有没有真正复用。很多“已配置”其实只是假象。
- 过滤
Preload类型请求，确认出现且状态码是200 - 检查该 URL 后续是否再次作为
Stylesheet/Script/Font出现 —— 如果有，说明路径不一致（比如大小写、/结尾、查询参数差异） - 打开
Application → Fonts面板，确认预加载字体显示为loaded状态，而非pending或空白 - 在 Network 面板中 hover 该 Preload 请求，看 Priority 是否为
high；若显示low或未标注，基本是as写错或缺失
media 属性让 preload 更精准，但也更危险
media 控制“是否发起请求”，但不控制“JS 或 CSS 里是否引用”。这点极易被忽略，导致小屏设备也加载高清图并丢弃。
- 写了
media="(min-width: 768px)"预加载桌面图，但 JS 逻辑在所有尺寸下都调用document.querySelector('.hero-img').src = 'desktop.jpg'→ 小屏照样发请求，纯属浪费 - 响应式字体预加载时，
media应与实际 CSS 中的@font-face规则匹配，否则字体不会被激活 - 不要依赖
media来“省流量”，真正省流量的是按需加载逻辑本身；media只是辅助，不能替代 JS 判断
as 类型匹配——这两点不出错，preload 才算真正落地。其余优化再炫技，也抵不过一个大小写错误导致的重复请求。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
