preconnect比dns-prefetch更有效，因其不仅完成dns解析，还提前执行tcp握手和tls协商，使后续请求可直接复用连接，节省100–300ms延迟；而dns-prefetch仅止步于dns查询。
preconnect 为什么比 dns-prefetch 更有效
因为 preconnect 不只做 DNS 查询，它会提前完成 DNS 解析 + TCP 握手 + TLS 协商三步，让后续真实请求直接复用已建立的连接。而 dns-prefetch 只到 DNS 查询为止，真正发请求时仍要等 TCP/TLS，延迟多出 100–300ms（尤其在移动网络或高 RTT 场景）。Chrome、Firefox、Edge 等主流浏览器从 2019 年起已全面支持 preconnect，没必要再用 dns-prefetch 做主力。
哪些域名该加 preconnect
只对 HTML 中**实际引用了资源**的第三方或 CDN 域名加 preconnect，比如：
-
https://fonts.googleapis.com（用了 Google Fonts） -
https://cdn.example.com（静态资源托管在独立子域） -
https://api.example.com（首屏 JS 会立即 fetch 的接口域名）
不加的情况包括：
- 纯同源资源（
https://your-site.com）—— 浏览器自动复用主连接 - 只在用户操作后才访问的域名（如点击“登录”才调用的 auth.example.com）
- 未配置
crossorigin的跨域字体或脚本——preconnect会失败且无提示
preconnect 的 crossorigin 属性怎么填
必须显式写 crossorigin，哪怕目标是同协议同域（如 https://cdn.example.com）。原因：浏览器内部把带 crossorigin 和不带的连接视为两个不同连接池，漏写会导致后续 fetch 无法复用已建立的连接。
正确写法：
<link rel="preconnect" href="https://fonts.googleapis.com" crossorigin><link rel="preconnect" href="https://cdn.example.com" crossorigin>
错误写法：
-
<link rel="preconnect" href="https://fonts.googleapis.com">（漏crossorigin） -
<link rel="preconnect" href="http://cdn.example.com" crossorigin>（协议不一致，连接无法复用） -
<link rel="preconnect" href="//cdn.example.com" crossorigin>（协议相对路径，部分浏览器不识别）
怎么验证 preconnect 是否生效
打开 Chrome DevTools → Network 面板 → 切换到 Timing 标签页，找任意一个来自目标域名的资源（比如 font.woff2），展开 Timing，看 “Connection Start” 时间是否明显早于 “Request Start”。更直接的方式是过滤 Initiator 列为 preconnect，确认有对应请求；同时检查该域名下其他资源的 Priority 是否为 Highest 或 High（说明连接已就绪并被复用）。
容易被忽略的一点：preconnect 是“连接预热”，不是资源下载。它不会触发任何数据传输，也不会占用带宽，但会占用浏览器有限的并发连接数（通常最多 6 个）。加太多反而可能挤掉主域关键请求。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
