preconnect 和 dns-prefetch 是按需单选、严格分域的关系：同一域名只能选其一，跨域名才可并存；preconnect 用于确定性高且需 CORS 的关键跨域资源，dns-prefetch 适用于低优先级或不确定使用的域名。
直接结论：preconnect 和 dns-prefetch 不是“搭配使用”的关系，而是「按需单选 + 严格分域」——同一域名只能选其一，且必须根据资源确定性、CORS 需求和协议支持来判断；跨不同域名才可并存。
什么时候必须用 preconnect 而不是 dns-prefetch
当你确认页面首屏一定会从某个跨域域名加载关键资源（比如字体、首屏 JS/CSS、立即调用的 API），且该域名支持 HTTPS 并涉及 CORS（如字体、带凭据的 fetch），就必须用 preconnect：
-
preconnect会真实完成 DNS + TCP + TLS 三步，省下 200–600ms，但占用连接池槽位（HTTP/1.1 下最多 6 个） - 必须显式写协议（
https://）并带上crossorigin属性，否则 Safari 和旧 Chrome 会降级为普通连接 - 例如 Google Fonts 的两个独立域名：
<link rel="preconnect" href="https://fonts.googleapis.com">和<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>——缺一不可，也不能合并
什么时候只用 dns-prefetch 更安全
对那些“可能用到但不紧急、不确定是否真发起请求、或仅需最低开销预热”的域名，选 dns-prefetch：
- 它只做 DNS 查询，毫秒级开销，IE11 都支持，不占连接池，也不触发 TLS
-
href必须是协议相对写法（//cdn.example.com）或显式 HTTPS，不能带路径、端口、参数；写成http://在 HTTPS 页面中大概率被跳过 - 适合埋点上报、备用 CDN、广告域名等非关键路径，比如：
<link rel="dns-prefetch" href="//metrics.example.com"> - 注意：浏览器 DNS 并发队列通常限 6～10 个，乱加会挤占真实请求的调度优先级
混用同一域名的后果：静默失效，纯属冗余
如果对同一个域名既写了 dns-prefetch 又写了 preconnect，浏览器会直接忽略前者——因为 preconnect 已隐含 DNS 解析，且优先级更高：
立即学习“前端免费学习笔记（深入）”；
- ❌ 错误示例：
<link rel="dns-prefetch" href="//cdn.example.com">+<link rel="preconnect" href="https://cdn.example.com" crossorigin> - ✅ 正确做法：删掉
dns-prefetch，只保留preconnect；若后续发现该域名实际很少用，再换回dns-prefetch - 别为子域名单独 preconnect（如
a.example.com和b.example.com），优先 preconnect 根域名example.com更高效
位置和写法错误是最常见的失效原因
这两个标签都极度依赖解析时机和语法精度，放错位置或写错 href 基本等于没写：
- 必须放在
<head>中，且在<meta charset>和<title>之后、首个<link rel="stylesheet">或<script>之前 - 动态插入（
document.createElement('link')）、塞进<body>或<template>里，全部无效 -
dns-prefetch写https://cdn.example.com/js/app.js？整个标签被静默丢弃——浏览器只认主机名，路径一概忽略 -
preconnect漏掉crossorigin？目标资源若需凭证（如字体），连接无法复用，白建一次 TLS
真正容易被忽略的点是：它们不解决缓存命中率问题，也不加速同源请求；只影响「首次访问时第三方域名的连接建立速度」。如果页面已缓存了 DNS 或连接，这些标签几乎不产生可观测收益——所以别在本地调试时盯着 Lighthouse 分数改，要结合真实弱网首屏加载日志验证效果。
