preconnect仅对明确几秒内必发的跨域https资源有效，需置于最顶部、带crossorigin（若需cors）、限3–6个首屏强依赖域名，同源或http域名无效。
缩短关键外部文档的握手延迟">
preconnect 不是万能加速器，它只在你明确知道要访问某个外部域名、且该域名尚未建立连接时才有效。盲目添加反而浪费浏览器资源，甚至拖慢首屏。
什么时候该用 preconnect？
典型场景：页面中必然要加载的第三方资源，比如 CDN 上的字体（fonts.googleapis.com）、分析脚本（www.google-analytics.com）、或核心 API 域名（api.example.com）。这些资源通常在 HTML 解析后期才被发现，但握手（DNS + TCP + TLS）耗时可能达数百毫秒。
- 必须是跨域域名，同域资源不需要
preconnect - 该域名后续确实会被请求（如
<link href="https://cdn.example.com/main.css" rel="stylesheet">），否则预连白做 - 优先级高于
dns-prefetch，因为它会真正发起 TCP/TLS 握手，不只是查 DNS
preconnect 必须写在
浏览器只有在解析到 <link rel="preconnect"> 时才会启动预连接。如果它出现在 或靠后位置，可能错过关键窗口期。
- 放在
<meta charset>和<title></title>之后、任何<script></script>或样式表之前最稳妥 - 不要用 JavaScript 动态插入 ——
document.createElement('link')创建的preconnect不生效 - 每个域名只需一个
preconnect，重复声明无意义，还占解析带宽
常见错误：漏掉 href 或写错协议/端口
以下写法全部无效：
<link rel="preconnect" href="googleapis.com"><!-- 缺少协议，浏览器无法解析 --><link rel="preconnect" href="//fonts.googleapis.com"><!-- 协议相对路径，不支持 preconnect --><link rel="preconnect" href="https://fonts.googleapis.com:443"><!-- 显式写 :443 是冗余且部分浏览器忽略 -->
正确写法只有一种：
<link rel="preconnect" href="https://fonts.googleapis.com">
-
href必须含完整协议（https://或http://），不能省略 - 不要加路径（如
/css）或查询参数，只保留域名和可选端口（一般不用写） - HTTP/2 或 HTTP/3 环境下，对同一域名多次
preconnect不会复用连接，但也不报错；关键是别写错
配合 crossorigin 才能对 CORS 资源生效
如果预连的域名后续要加载带凭据（credentials）的资源（比如字体、带 cookie 的 API），必须显式声明 crossorigin 属性，否则浏览器会忽略预连或降级为普通连接。
<link rel="preconnect" href="https://fonts.googleapis.com" crossorigin>
- 即使资源本身没设
crossorigin，只要它实际走 CORS 流程（如font-display: swap加载的 WOFF2），就需这个属性 -
crossorigin=""和crossorigin等效；写成crossorigin="anonymous"也行，但没必要 - 不加
crossorigin时，浏览器可能悄悄放弃已建立的连接，导致后续请求仍要重握手
真正起作用的不是标签本身，而是你是否清楚那个域名会在哪一刻被首次请求、是否带凭据、是否已被其他 tab 占用连接池 —— 这些细节决定了 preconnect 是提速还是添乱。
