dns-prefetch仅执行DNS解析，不建连、不保活；preconnect则完成DNS+TCP+TLS全过程，但也不保活，连接复用由HTTP协议层（如HTTP/2）自动管理。
直接说结论：dns-prefetch 只做 DNS 解析，不保活；preconnect 才能建连 + TLS 握手，但也不“保活”。所谓“长连接保活”是 HTTP/1.1 的 Connection: keep-alive 或 HTTP/2+ 的复用机制，跟这两个标签无关。
为什么 dns-prefetch 不能替代 preconnect
dns-prefetch 的作用非常单一：只触发一次 DNS 查询，并缓存结果（TTL 内有效）。它不发任何 TCP 包，更不会握手、发送 HTTP 请求或维持连接。
- 你写了
<link rel="dns-prefetch" href="//api.example.com">，浏览器只查 IP，查完就停 - 后续首次
fetch("https://api.example.com/data")仍要走完整 TCP + TLS 流程，只是省掉了 DNS 阶段 - 如果页面里根本没发请求，这个预解析结果可能被丢弃（尤其内存紧张或弱网时）
-
preconnect则会真正发起 TCP 连接并完成 TLS 握手（HTTPS 域名），相当于把“连接池”提前准备好
preconnect 能建连，但不是“长连接保活”
preconnect 是一次性动作：浏览器在空闲时建立连接，然后交给底层网络栈管理。它不控制连接是否复用、是否关闭，也不干预 HTTP 层的 keep-alive 行为。
- 连接建立后，若后续请求命中同一域名+端口+协议，HTTP/2+ 会自动复用；HTTP/1.1 是否复用取决于服务端响应头和客户端策略
- 没有“保活心跳”机制——浏览器不会主动发 ping 包维持连接；连接空闲超时后由 TCP 栈或服务端决定是否断开
- 写错
crossorigin（比如 HTTPS 域名漏掉）会导致 Safari/旧 Edge 忽略该标签，连接根本不会建 - 并发上限通常为 6 个，多写几个
preconnect不等于多建几条“长连接”，反而可能挤占主站资源
怎么判断该用 dns-prefetch 还是 preconnect
核心看两点：你是否「马上要用」这个域名，以及它是否支持 HTTPS。
立即学习“前端免费学习笔记（深入）”；
- 确定首屏后 100ms 内必发请求 → 用
<link rel="preconnect" href="https://api.example.com" crossorigin> - 只是“可能用到”，比如用户点击后才加载第三方组件 → 用
<link rel="dns-prefetch" href="//widget.example.com"> - 目标域名只支持 HTTPS，但当前页是 HTTP →
//写法会降级失败，必须改用preconnect并显式写https://+crossorigin - 同一域名同时写了两个 →
preconnect生效，dns-prefetch被静默忽略
验证是否真起作用，别信代码写了就行
加了标签不等于生效。DNS 缓存和连接状态得靠工具确认：
- Chrome DevTools → Network → Filter 选
Other→ 找目标域名请求，看domainlookup时间是否接近0ms（说明 DNS 命中） - 地址栏输入
chrome://net-internals/#dns→ 刷新页面后搜索域名 → 看是否出现在缓存列表、TTL 是否 > 0 - Network → 查看对应域名的首个请求 → 检查
connectStart和secureConnectionStart时间差：若后者远小于前者，说明 TLS 已预热（preconnect成功） - 别依赖
document.createElement('link')动态插入 —— 流式解析下，此时 HTML 已过半，DNS 查询大概率来不及
真正容易被忽略的是：浏览器对这些提示不保证执行，尤其在低端设备、弱网或内存吃紧时会直接跳过。所以优先级永远是「少而准」——只加首屏后立刻用、且确定跨域的那 1–3 个域名，而不是堆满整个 <head>。
