as属性必须精确匹配资源真实类型，因为它是浏览器调度资源的强制开关：写错或漏写会导致静默失效、优先级降为low、缓存无法复用，如字体不渲染、脚本重复下载、图片不被复用。
资源预加载不是 HTML 的装饰功能，它直接参与浏览器的资源调度决策；用错 as、路径动态拼接、或把非首屏资源塞进去，HTML 代码质量会从“结构清晰”退化为“性能毒药”。
为什么 as 属性必须精确匹配资源真实类型
as 决定浏览器是否把它当关键资源处理——写错就等于没写。比如字体文件用了 as="fetch"，浏览器按低优先级下载，FOIT（文字不可见闪屏）照常发生；as="script" 却漏掉，后续 <script src></script> 就无法复用缓存，白下一次。
-
as="font"→ 强制触发 CORS 检查，且必须配crossorigin，否则字体不渲染 -
as="style"→ 浏览器允许后续<link rel="stylesheet">复用该缓存，但写成as="fetch"就失效 -
as="image"→ 支持imagesrcset匹配逻辑；写成as="fetch"会导致高分辨率图没被选中
哪些资源路径能安全加 preload
只有路径在构建时完全确定、无运行时变量的资源才适合硬编码进 <link rel="preload">。Webpack 打包后的哈希文件名（如 /js/main-abc123.js）可以，但带模板变量的不行——href="/fonts/<code>theme.woff2" 这种写法在 HTML 解析阶段就被忽略，根本不会发起请求。
- ✅ 同构生成的静态路径：
/assets/fonts/inter-latin.woff2 - ✅ 构建产物中已知的 chunk 名：
/js/chunk-chart.a1b2c3.js - ❌ SSR 中动态插入的路径：
/js/<code>dynamicChunkName.js - ❌ 带 query 参数的 URL：
/api/data.json?t=<code>timestamp（缓存不可控，且浏览器可能拒绝 preload）
如何验证 preload 是否真正生效
不能只看 Network 面板有没有那个请求，得看它是否被正确调度和复用。
- 在 Chrome DevTools 的 Network 面板，筛选该资源，检查
Priority列是否为Highest或High；如果是Low或Medium，基本是as错了或路径 404 - 打开 Coverage 面板，加载页面后看预加载的 JS 文件是否出现在“未使用代码”里——如果占比很高，说明它被提前下了但根本没被
import()调用，属于冗余 preload - 对比同一资源在
preload和后续<img src>中的响应头：若cache-control不一致或 ETag 不同，说明浏览器没复用缓存，大概率是两次as类型不一致（比如一次as="image"，一次没写as）
最常被跳过的细节是：preload 只改下载时机，不缩小体积、不加速服务器响应、也不解决 DNS 查询延迟。你给一个 5MB 的视频加 as="video"，它照样拖慢首屏——这时候该做的是压缩、懒加载或用 preload 换成首帧 poster 图片。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
