preload适用于当前页面首屏强依赖资源，如关键CSS、Web Font、内联前JS等；prefetch用于下页可能用到的资源；普通link会阻塞渲染。as属性必须准确匹配资源类型（如font需as="font"+crossorigin），否则失效。
用 link rel="preload" 能提前触发关键资源下载，但不执行、不阻塞渲染——前提是路径正确、as 类型匹配、且资源确实在后续 HTML/CSS/JS 中被实际用到，否则就是白忙活。
什么时候该用 preload，而不是 prefetch 或普通 link？
核心区别在「时机」和「用途」：preload 是告诉浏览器“这个资源我马上就要，现在就下”，适用于当前页面首屏强依赖的字体、关键 CSS、内联前的 JS、Web Worker 脚本等；prefetch 是“可能下个页面要用”，由浏览器按空闲程度决定是否加载；普通 link（如 rel="stylesheet"）则会阻塞渲染直到加载并解析完成。
常见误用场景：
- 把非首屏图片或懒加载模块的 JS 用
preload—— 浪费带宽，还可能挤占真正关键资源的请求带宽 - 对已通过
import()动态导入的代码做preload—— 浏览器无法静态分析依赖，preload不会被触发 - 用
prefetch替代preload加载首屏 Web Font —— 字体加载延迟直接导致 FOIT/FOUT 加剧
as 属性必须填对，否则浏览器会忽略或降级处理
as 不是可选提示，而是强制声明资源类型。浏览器靠它决定请求优先级、CSP 策略、是否复用连接、是否允许跨域凭据等。填错等于没写。
立即学习“前端免费学习笔记（深入）”；
典型对应关系：
- CSS 文件 →
as="style"（不是"stylesheet"） - 字体（WOFF2/WOFF）→
as="font"，且必须加crossorigin属性（字体加载默认匿名模式） - JS 脚本 →
as="script"；如果是模块脚本，用as="script" type="module" - 关键 JSON 数据（如初始化配置）→
as="fetch"，并配crossorigin（fetch 请求默认带凭据）
错误示例：<link rel="preload" href="/main.js" as="javascript"> —— as="javascript" 无效，浏览器无视该标签。
路径、HTTP 状态码和缓存头直接影响预加载是否生效
preload 是独立 HTTP 请求，和后续真实使用时的请求完全解耦。哪怕 HTML 里写了 preload，只要资源返回 404、500、重定向或缓存头禁止缓存（如 Cache-Control: no-store），浏览器就不会把预加载结果用于后续使用。
调试要点：
- 检查 Network 面板：确认
preload请求状态码为 200，且响应头含content-length和合理cache-control - 避免相对路径歧义：用
/assets/font.woff2而非./font.woff2，防止当前 URL 带查询参数时路径解析出错 - 服务端不要对
preload请求做特殊拦截（比如某些 CDN 会过滤无User-Agent的请求）
一个易忽略点：如果预加载的字体文件被 Service Worker 拦截但未正确 respondWith()，页面后续实际使用时会 fallback 到系统字体。
Chrome DevTools 里怎么验证 preload 是否起作用？
打开 DevTools → Network → 刷新页面 → 筛选 Preload 列（需右键表头勾选），看是否有对应资源；再点开该请求，确认 Initiator 显示为 HTMLParser（说明来自 link 标签），而非 Script 或其他。
更关键的是比对时间线：
- 找到后续真实使用该资源的时机（比如 CSS 中
@font-face触发字体加载、script标签执行） - 确认其发起时间晚于
preload完成时间，且复用同一 connection（Connection ID 相同） - 若看到两个独立请求（一个 Preload，一个 Fetch），说明浏览器没复用——大概率是
as错了或 CORS 不匹配
真正难调的不是写法，是让浏览器“信你”，然后安静地复用那个预加载下来的字节流。
