dns-prefetch仅提前解析dns并缓存ip，不建连、不握手、不下载资源；需写为//或https://开头，置于meta和title后、首个外部资源前，仅对后续异步请求生效。
它不加速首屏，也不建连接，只提前查一次 DNS 并缓存 IP —— 本质是把“等 DNS 返回”这个环节挪到页面加载空闲期去干。
dns-prefetch 只做 DNS 解析，不发 TCP 包
浏览器拿到 <link rel="dns-prefetch" href="//cdn.example.com"> 后，仅触发一次异步 DNS 查询（A/AAAA 记录），查完就把 IP 缓存进本地 DNS 缓存表。后续真实请求（比如 fetch("https://cdn.example.com/api") 或 <img src="https://cdn.example.com/logo.png?x-oss-process=image/resize,p_40">）发起时，直接跳过 DNS 阶段，省下 20–100ms。
它不做以下任何事：
- 不建立 TCP 连接
- 不进行 TLS 握手
- 不占用 HTTP 连接池 slot
- 不下载任何资源内容
为什么必须用 // 或显式 HTTPS？
浏览器解析 href 时只提取主机名，其余全丢。写错格式就静默失效，且控制台零报错。
-
//cdn.example.com：协议相对写法，适配当前页协议（HTTP 页面走 HTTP，HTTPS 页面走 HTTPS），兼容 Safari 旧版本 -
https://fonts.googleapis.com：显式 HTTPS，在现代环境更稳；但若当前页是 HTTP，部分浏览器会忽略 -
http://api.example.com：HTTPS 页面大概率跳过，混合内容策略拦截 -
cdn.example.com：缺//，被当成本地路径，查的是your-site.com/cdn.example.com -
//cdn.example.com/js/app.js：含路径，整个标签被丢弃
为什么位置靠前才有效？
浏览器流式解析 HTML，<link rel="dns-prefetch"> 一旦被读到就立即排队执行 DNS 查询。如果它出现在首个 <link rel="stylesheet"> 或 <script></script> 之后，很可能 DNS 查询还没轮到，相关资源请求已经发出。
- ✅ 推荐位置：
<meta charset>和<title></title>之后、首个外部资源标签之前 - ❌ 无效位置：塞在
里、包在<template></template>中、JS 动态插入（document.createElement('link')） - ⚠️ Safari 更保守，可能延迟到空闲或用户交互后才执行，所以位置更要靠前
哪些域名值得加？哪些纯属浪费？
dns-prefetch 是真实 DNS 查询，浏览器并发上限通常为 6～10 个。加错对象既占队列，又干扰关键请求。
- ✅ 值得加：
//cdn.example.com（图片/JS/CSS 真实加载）、//api.example.com（首屏后立即fetch）、//hm.baidu.com（统计 SDK 初始化必发） - ❌ 不该加：
//your-site.com（同源，浏览器已缓存或自动优化）、//admin.example.com（子域共享主域 DNS 缓存）、//ad.doubleclick.net（不稳定、常被拦截） - ⚠️ 注意：
//tongji.example.com和//log.example.com是两个独立域名，不能只加一个
最常被忽略的一点：它对「首次请求」无感——只有当 JS 懒加载、用户滚动触发动态 fetch、字体 CSS 异步加载这类行为真正发生时，预解析的 IP 才派上用场。写对了位置和格式，却没对应上真实异步请求场景，等于白加。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
