先说一个很多人踩过的坑：你辛辛苦苦在 HTML 里加了 ，以为能省点 DNS 查询和 TCP 握手的时间，结果实际请求一来，浏览器建立的那个连接压根没被复用——预连白做了，甚至还拖慢了页面加载。
问题出在哪？就出在 preconnect 这种机制的底层逻辑上。
一句话总结：preconnect 对 CDN 负载均衡域名无效，加了不仅不省时间，反而可能干扰真实请求的调度。
为什么 preconnect 不能用于 CDN 的负载均衡域名
CDN 的负载均衡，通常靠 DNS 返回多个 A/AAAA 记录（比如轮询或根据地理调度），或者用 Anycast + 任播路由来实现。而浏览器处理 preconnect 的逻辑是：它只认 href 里写死的那个单个域名，然后对这个域名发起连接，并且这个连接会绑定到 DNS 解析出来的某个 IP 上（通常是第一个解析到的）。它可不会去预连整个 IP 池，更不会去管后续的真实请求会被调度到哪个节点上。
- 你写
，浏览器就只连其中一个 IP。但真实资源请求，很可能因为 DNS 轮询或者 Anycast 调度，落到另一个节点上——预连白做。 - 一些 CDN（比如 Cloudflare、Akamai）会动态返回不同的 IP。浏览器通过
preconnect建立的那个连接，很可能在真实请求发起时已经失效，或者跟实际要连的节点不匹配，无法复用。 - Chrome 最多只允许同时并发 6 个
preconnect。你把宝贵名额浪费在负载均衡域名上，就等于挤掉了那些真正确定的、需要预连的静态资源域名（比如fonts.gstatic.com），反而拖慢了其他关键资源的加载。
本质上，preconnect 预设的场景是一个确定的目标，但 CDN 负载均衡域名天然是个“多选项”入口，两者在根本逻辑上就不兼容。
哪些 CDN 域名可以安全加 preconnect
那么，什么时候加 preconnect 才能真的奏效？答案是：只有当你明确知道资源固定从某个具体子域名加载，并且这个子域不参与任何负载跳转时才行。换句话说，你给的是一个“确定的地址”，而不是一个“调度入口”。
常见可加的场景：
https://static.example.com—— 这是专用静态资源子域，虽然也 CNAME 到了 CDN，但 DNS 不轮询，始终解析到同一组边缘节点。https://jsdelivr.net或https://cdn.jsdelivr.net—— 公共 CDN，虽然背后有复杂的负载均衡机制，但对外暴露的是一个稳定域名，浏览器连接能复用。https://fonts.gstatic.com—— Google Fonts 的字体托管域名，不存在负载跳转，而且必须加crossorigin。
一个典型的反面案例：你同时有 https://cdn-01.example.com 和 https://cdn-02.example.com 两个域名，并且前端 JS 会动态切换域名。这种情况下，preconnect 只能预连其中之一，另一个必然失效。
crossorigin 属性在 CDN 场景下的取舍
是否给 preconnect 加上 crossorigin，关键看你要加载的资源是否需要凭据或者触发 CORS 检查。
- 加载公开的 CSS/JS（比如
），如果服务端没返回Access-Control-Allow-Origin，那就不要加crossorigin，这样更稳妥。 - 用
fetch()请求 CDN 上的 JSON 配置文件，并且服务端已经设置了Access-Control-Allow-Origin: *，这时就必须加crossorigin="anonymous"，否则预连无法被复用。 - 需要注意：
crossorigin=""是非法写法，浏览器会直接忽略它。正确的写法是只写crossorigin或者crossorigin="anonymous"。
一个容易忽略的点是：crossorigin 的缺失或错误配置，会导致 preconnect 建立的连接无法被后续的 CORS 请求复用，这也是很多预连“失效”的隐藏原因。
验证 preconnect 是否真起作用
不要只看 HTML 里写了没，重点要看 DevTools 里 Network 面板的 Timing 有没有实际效果。
- 过滤出目标 CDN 域名的资源（比如
main.js），展开 Timing 信息，对比Connection Start和Request Start的时间差。理想情况是差值 ≤ 50ms，这说明连接已经提前就绪。 - 在 Network 面板顶部搜索
preconnect，确认 Initiator 列出现了对应的条目，并且状态码是(finished)。 - 如果发现该域名下所有资源的
Connection Start时间都晚于Request Start，那就说明preconnect实际上没有生效。原因很可能是域名不匹配，或者漏了crossorigin。
真正容易被忽略的是——CDN 域名到底是不是真的“固定”。很多团队觉得写了 cdn.example.com 就万事大吉了，但实际后端配置了 302 跳转，或者 JS 动态拼接了 URL，导致最终请求发到了完全不同的地址。这种情况下，你加的 preconnect 可以说一点用都没有。所以，验证这一步，值得你多花几秒时间。
