preconnect仅对首屏强依赖且100%会请求的第三方域名有效，如fonts.googleapis.com、fonts.gstatic.com、cdn及首屏api域名；须写在head最顶部，带crossorigin（若资源需cors），同域名仅声明一次。
只有明确几秒内必从某第三方域名加载关键资源时，preconnect 才真能减少延迟；加错、加多、加早或加晚，反而拖慢页面。
哪些域名该加 preconnect？
不是所有跨域请求都适合。只对「首屏强依赖、100%会发起请求」的第三方域名用：
-
https://fonts.googleapis.com和https://fonts.gstatic.com（Google Fonts 字体必须成对预连） -
https://cdn.example.com（你自己的静态资源 CDN，且首屏 CSS/JS 确实从它加载） -
https://api.example.com（首页 JS 初始化就fetch()它，且响应头含Access-Control-Allow-Origin） - 不适用：
http://域名（Chrome 直接忽略）、同源地址（如https://your-site.com）、广告/统计等非首屏必需域名
crossorigin 属性到底要不要加？
这不是可选项，是行为开关：目标资源实际需要 CORS 时，preconnect 必须带 crossorigin，否则浏览器建的连接无法复用，后续请求仍要重连。
- 必须加：
https://fonts.googleapis.com、https://fonts.gstatic.com（字体文件走 CORS）、API 域名且服务端返回了Access-Control-Allow-Origin - 可不加：纯静态 CDN（如
https://cdn.jsdelivr.net），且你没用credentials: 'include'发起请求 - 写法只能是
crossorigin或crossorigin="anonymous"；crossorigin=""是非法 HTML，会被忽略
preconnect 标签放哪儿才生效？
必须放在 最顶部，早于所有 <link rel="stylesheet"> 和 <script></script>。浏览器流式解析，晚几行就可能错过空闲连接窗口。
- 有效：
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> <link rel="stylesheet" href="https://fonts.googleapis.com/css2?..."> - 无效：放在
里、<link rel="preload">后面、或用 JS 动态插入 - 同一域名只写一次，重复声明（如两次
href="https://cdn.example.com"）后一次直接被丢弃
和 dns-prefetch 混用时怎么安排？
dns-prefetch 只做 DNS 查询，开销小、兼容性好；preconnect 做到 TLS 握手，更快但更重。两者可以共存，但得按确定性分级使用：
- 对「不确定是否真会访问」的域名（比如用户点击分享按钮才调用的
https://share.example.com），只加<link rel="dns-prefetch" href="https://share.example.com"> - 对「确定高频使用」的核心域名（如字体、CDN、首屏 API），优先加
preconnect，不用再额外加dns-prefetch - 别在一个域名上同时写两个——
preconnect已包含 DNS 查询，dns-prefetch多余
最容易被忽略的是：现代浏览器对每个域名最多维持 6 个并发连接，preconnect 占一个坑却不用，会卡住真实请求；而 HTTP/2 多路复用下，跨域连接收益本身就在下降。所以宁缺毋滥，只保最关键的 2–3 个域名。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
