该用preload而非prefetch的判断标准是资源在当前页面导航中是否“马上就要用”：是则用preload（如字体、首屏css、动态import的js模块），否则用prefetch（如下一页资源）；preload需带as和crossorigin才生效，prefetch则依赖空闲时机且不保证执行。
什么时候该用 preload 而不是 prefetch
判断标准就一条：这个资源在当前页面导航中是否「马上就要用」？是，才用 preload；否则一律用 prefetch 或不用。
-
preload会立刻发起 high 优先级请求，抢带宽、占连接池——它只适合字体（as="font"）、首屏 CSS（as="style"）、动态import()的 JS 模块（as="script"）这类 HTML 解析后期才发现、但渲染又等不及的资源 -
prefetch是 low 优先级，等window.onload后才动，适合用户行为可预测的下一页资源，比如首页「商品列表」按钮旁 prefetchdetail.js - 把
comments.js（下一页才用）写成preload，它会挤掉critical.css或首屏图，FCP 延迟 300ms+ 很常见
preload 必须带 as 和 crossorigin 才生效
漏写或写错 as，浏览器就当普通 fetch 处理，Priority 直接降为 Low，等于白写；漏 crossorigin 对字体类资源更是静默失败——Chrome 不报错，但字体死活不应用。
-
as="font"→ 必须配crossorigin，哪怕字体同域；否则下载完也进不了 font cache -
as="style"→ 需搭配onload="this.onload=null;this.rel='stylesheet'"，否则只下载不解析 -
as="script"→ 若后续仍用<script src></script>引同一 URL，能复用；但若有integrity，preload也得带上，否则缓存不匹配 -
as="image"→ 不支持srcset或sizes，只适合尺寸/格式确定的单图；对普通<img src>无效，现代浏览器已内置预解析
prefetch 不是“写了就下”，生效条件很脆弱
它依赖空闲时机、缓存策略和路径合法性，写对了也不保证执行。用户开省流模式、网络是 2G、内存紧张，都可能跳过它。
- 必须同源，跨域
prefetch在 Chrome/Firefox 中基本被无视（即使服务端开了 CORS） - 响应头必须含
Cache-Control: public, max-age=31536000，否则跳转后缓存失效，白下 - 路径必须为绝对或根相对（如
/js/next-page.js），子路径下易解析失败 - 别
prefetch整个详情页 HTML——浏览器只缓存 raw bytes，不会预解析，后续仍需完整导航流程
验证是否真起作用，不能只看 HTML 有没有那行
打开 Chrome DevTools → Network 面板，筛选和检查要具体：
- 按
Initiator列筛选：preload请求的 Initiator 应为preload，prefetch应为prefetch；若是parser或script，说明没生效或被覆盖 - 查
Priority列：preload必须是Highest或High；若显示Medium或Low，大概率是as漏写、写错，或没加crossorigin - 点开请求详情，确认 Response Headers 中有
crossorigin（跨域字体必需），且状态码是200（from memory cache）或304（跳转后）
最容易被忽略的点是：preload 和 prefetch 都无法绕过关键渲染路径本身——它们只是调度提示，不是性能银弹。资源体积大、RTT 高、服务器慢，这些底层问题，靠加标签解决不了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
