Resource Hints 是浏览器解析 HTML 时决定资源加载优先级的关键信号；preconnect 做 DNS+TCP+TLS 三步预连接，dns-prefetch 仅做 DNS 预解析；preload 声明当前页必用高优资源且须带 as 属性，prefetch 仅空闲时低优预取后续页资源；误用会导致 FOIT、重复请求或失效。
HTML 资源提示（Resource Hints）不是“可有可无的优化技巧”，而是浏览器解析 HTML 时就决定资源加载优先级的关键信号——用错或漏用，preconnect 可能变成阻塞点，preload 可能触发重复请求，prefetch 在 SPA 路由切换时根本不会生效。
什么时候该用 preconnect 而不是 dns-prefetch
preconnect 做的是 DNS 查询 + TCP 握手 + TLS 协商三件事，dns-prefetch 只做 DNS 查询。如果目标域名后续要加载跨域资源（比如 CDN 上的 JS/CSS/字体），且你确定一定会用，优先选 preconnect；但如果只是“可能用到”或目标站不支持 HTTPS（导致 TLS 协商失败），dns-prefetch 更安全。
-
preconnect必须配合href和可选的crossorigin属性，跨域资源不加crossorigin会静默失败 - 不要对超过 6 个域名使用
preconnect，Chrome 限制并发 preconnect 数量，多余项会被丢弃 -
dns-prefetch不受 CORS 影响，也无需crossorigin，适合兜底场景
preload 和 prefetch 的本质区别在哪
preload 是“当前导航必须用”的高优先级资源声明，浏览器会立即发起请求（即使资源不在当前视口）；prefetch 是“后续导航可能用”的低优先级资源预取，只在浏览器空闲时下载，且仅对同域或明确配置了 CORS 的跨域资源有效。
-
preload必须指定as属性（如as="script"、as="font"），否则浏览器无法正确设置请求头和优先级 -
prefetch不支持as，也不参与当前页面渲染流程，SPA 中需手动触发（比如路由进入前调用link[rel=prefetch]的load事件） - 误把字体用
prefetch加载会导致 FOIT（字体闪白），必须用preload+as="font"+crossorigin
如何避免 preload 触发重复请求
浏览器对同一 URL 的 preload 和后续真实资源引用（如 <script src="a.js">）会自动去重，但前提是 URL 完全一致（包括查询参数、大小写、编码）。常见翻车点：
立即学习“前端免费学习笔记（深入）”；
- 构建工具自动注入 hash（如
a.12345.js），但preload写死为a.js→ 两个请求都发 - CDN 开启了 query 参数忽略策略，但浏览器认为
a.js?v=1和a.js?v=2是不同资源 - HTTP/2 Server Push 已推送资源，再
preload同一资源 → 浏览器仍会发请求（Push 不影响 preload 行为）
解决办法：服务端渲染时动态注入带 hash 的 preload，或用 webpack 的 PreloadPlugin 自动生成匹配的标签。
第三方脚本能不能用 preconnect 或 preload
可以，但必须满足两个硬性条件：第三方资源支持 CORS，且你明确知道它的最终加载时机。例如 Google Analytics 的 gtag.js 通常由内联脚本动态加载，此时 preload 它毫无意义——浏览器还没执行到创建 script 标签的逻辑，preload 请求早已超时或被取消。
- 广告、统计类脚本大多走异步动态插入，只适合
preconnect到其主域名（如https://www.googletagmanager.com） - 字体托管服务（如 Google Fonts）推荐
preconnect+preload组合：preconnect到https://fonts.googleapis.com和https://fonts.gstatic.com，再preload具体字体文件 - 任何
preload的第三方资源，都应在<head>中紧邻其真实引用位置之前，否则可能因加载顺序错乱失效
最常被忽略的一点：Resource Hints 不是“写上去就起效”，它依赖浏览器是否真正执行了对应阶段的优化逻辑——比如 Safari 对 prefetch 支持极弱，而 Chrome 90+ 已废弃 subresource。上线前务必用 Network 面板确认请求是否发出、是否复用连接、是否被降级。
