应优先对页面确定1秒内必用的关键https第三方域名（如cdn、字体、核心api）使用preconnect，因其提前完成dns+tcp+tls三步，弱网下可省200–600ms；dns-prefetch仅做dns解析，适合低频或非紧急跨域场景。
什么时候该用 preconnect 而不是 dns-prefetch
当第三方资源（比如 CDN 域名、分析脚本、广告平台）明确需要建立 TLS 握手或跨域连接时，preconnect 才比 dns-prefetch 有价值。DNS 查询快，但 TCP+TLS 建立耗时更长，尤其在移动网络下。
常见误用是给所有第三方域名都加 preconnect——这反而会抢占主域连接数，触发浏览器并发限制（Chrome 默认最多 6 个 preconnect 同时生效），甚至阻塞关键资源加载。
- 只对已知会立即发起 HTTPS 请求的第三方域名使用，例如：
https://stats.example.com、https://cdn.jsdelivr.net - 避免对未启用 HTTPS 的域名使用，
preconnect会失败且不降级 - 不要为子域名泛用，比如写了
preconnect到https://api.example.com，但实际请求发往https://v2.api.example.com，连接无法复用
preconnect 必须写在
浏览器只有在解析到 preconnect 标签后才会启动预连接，如果它被 JS 动态插入、或放在 里，基本无效——此时关键请求可能早已发出。
典型错误写法：<script>document.head.append(...)</script> 或放在 底部。
- 必须是静态
<link rel="preconnect" href="https://thirdparty.com">，且位于中<title></title>之后、<meta charset>之后（顺序不影响功能，但早解析早触发） - 如果第三方服务支持
crossorigin（如字体、CDN 资源），记得加上：<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>，否则预连接可能被忽略 - 多个
preconnect不会自动去重，重复声明同一域名会浪费连接槽位
如何验证 preconnect 是否真正生效
不能只看 HTML 里有没有写，得看 Network 面板里对应域名是否出现 initial connection 时间提前、且状态为 finished（非 cancelled 或 pending）。
常见失效信号：preconnect 显示 queued 状态超过 500ms，或后续真实请求仍显示 connect 耗时 > 200ms（说明没复用）。
- 打开 Chrome DevTools → Network → 右键表头勾选
Connection ID和Protocol，观察目标域名的连接 ID 是否与preconnect条目一致 - 用
chrome://net-internals/#events搜索HOST_RESOLVER_MANAGER和SSL_CLIENT_SOCKET事件，确认预连接阶段是否完成 TLS 握手 - 注意：本地开发环境下因代理、HTTPS 证书问题，
preconnect往往不生效，务必在真实 HTTPS 环境下测试
第三方服务域名变更时最容易漏掉 preconnect
很多团队上线新 CDN、切流量到备用分析服务商、或升级广告 SDK 后，只改了 JS URL，却忘了同步更新 preconnect 声明——结果新域名完全没预连接，首屏性能倒退。
这不是配置遗漏，而是发布流程断点。没有自动化检查，就大概率出问题。
- 把
preconnect域名和实际资源请求域名纳入 CI 构建校验，比如用 Puppeteer 抓取 HTML + JS 中所有第三方域名做比对 - 避免硬编码，可考虑用构建时模板注入（如 Webpack DefinePlugin 或 Vite env），让
preconnect和资源地址共用同一变量 - 监控线上
resource timing API中connectStart - domainLookupStart差值突增，往往就是预连接失效的信号
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
