preconnect是浏览器提前与目标域名建立tcp连接（含tls握手）的提示机制，不下载资源；仅当明确后续会从该域名加载关键资源（如字体、cdn js/css、首屏api）时才应使用，需写在中且避免重复、http协议或盲目添加。
preconnect 是什么，什么时候该用
preconnect 是浏览器提前与目标域名建立 TCP 连接（含 TLS 握手）的提示机制，不下载任何资源。它只在你明确知道后续会从某域名加载关键资源（比如字体、API、CDN JS/CSS）时才值得加。盲目添加反而浪费连接数、挤占真实请求带宽。
典型适用场景：https://fonts.googleapis.com（Google Fonts）、https://cdn.example.com（静态资源 CDN）、https://api.example.com（首屏需调用的接口域名）。
不适用场景：第三方广告、分析脚本、未确认是否真会访问的备用域名；HTTP/2 多路复用下跨域收益也明显下降。
怎么写 preconnect link 标签
必须写在 中，且越靠前越好（早于 <link rel="stylesheet"> 或 <script></script>）。格式固定，不能省略 href，也不能加 crossorigin 除非目标资源本身需要 CORS：
<link rel="preconnect" href="https://fonts.googleapis.com"><link rel="preconnect" href="https://cdn.example.com" crossorigin>
注意点：
-
crossorigin属性不是可选开关——如果目标资源（如字体、图片）实际响应头含Access-Control-Allow-Origin，而你没加crossorigin，浏览器会忽略该preconnect，甚至报Failed to execute 'fetch' on 'Window': Request mode is 'no-cors' but the URL's origin is not the same as the document's - 不要对
http://域名使用preconnect（现代浏览器直接忽略） - 一个域名只写一次
preconnect，重复声明无意义
和 dns-prefetch、preload 的区别在哪
三者常被混用，但行为层级完全不同：
-
dns-prefetch只做 DNS 查询，最快最轻量，适合所有外部域名（包括非 HTTPS），但无法覆盖 TCP/TLS 开销 -
preconnect做到 TCP + TLS，耗时更长，但为后续请求节省最多 100–500ms（尤其高延迟网络），只推荐给确定要访问的 2–3 个核心域名 -
preload是强制提前获取某个具体资源（如<link rel="preload" href="/font.woff2" as="font">），和域名无关，别拿它替代preconnect
常见错误：用 preload 去“预加载”一个域名（href 写成 https://cdn.com）——这根本不会触发任何网络行为，浏览器直接忽略。
怎么验证 preconnect 是否生效
打开 Chrome DevTools → Network 面板 → 刷新页面 → 点击任意请求 → 查看 Timing 标签页：
- 若看到 “Connection Start” 时间显著早于首个同域名资源的 “Request Start”，说明
preconnect起作用了 - 若 “Connection Start” 和 “Request Start” 几乎重合，检查是否漏了
crossorigin、域名拼写错误、或浏览器已缓存连接（此时可清空缓存重试） - 在 Application → Frames → 主帧的 “Manifest” 或 “Service Workers” 旁看不到
preconnect记录——它不进这些面板，只影响 Network 时间轴
真正容易被忽略的是：HTTPS 域名的 preconnect 在 HTTP/2 下可能被合并连接抵消收益，而 HTTP/1.1 环境下效果最明显。别只看 Lighthouse 报告里的“建议添加”，得结合实际网络环境和协议版本判断要不要加。
