dns-prefetch最早在浏览器流式解析到对应link标签时执行，必须置于head最前、用协议相对url写主机名，仅对即将在300ms内使用的第三方域名有效。
根本做不到“页面开始加载前”解析——dns-prefetch 的最早执行时机，是浏览器流式解析到该 <link> 标签的那一刻。 它不是魔法，不能在 HTML 字节还没到达时就干活；但可以做到「首屏资源请求发出前」完成 DNS 查询，前提是位置、写法、目标都精准。
为什么dns-prefetch必须放在
浏览器边下载 HTML 边解析（streaming parsing），遇到 <link rel="dns-prefetch"> 就立即排队执行 DNS 查询。如果它被塞在 <link rel="stylesheet"> 后面，CSS 请求很可能已发出去、甚至开始下载，预解析就彻底失去意义。
- ✅ 正确顺序：
<meta charset>→<title></title>→<link rel="dns-prefetch" href="//api.example.com">→ 首个外部 CSS/JS - ❌ 放在
里：绝大多数浏览器直接忽略 - ❌ 用 JS 动态插入：
document.createElement('link')太晚，DOM ready 都可能结束了 - ⚠️ Safari 更保守：即使位置正确，也可能延迟到空闲或用户交互后才查，所以越早放，越有机会抢在首屏请求前完成
href值写错就等于没写，且不报错
浏览器只从 href 中提取主机名，其余内容全被静默丢弃——你改了十次，控制台也不会提示一句错误，排查起来极难。
- ✅ 合法写法：
//cdn.example.com（协议相对，推荐）、https://fonts.googleapis.com（HTTPS 页面显式更稳） - ❌
https://cdn.example.com/js/app.js：含路径，整个标签被忽略 - ❌
http://api.example.com：HTTPS 页面下大概率跳过，旧版 Safari 尤其敏感 - ❌
cdn.example.com：缺协议标识，被当成本地路径处理，查的是当前域下的子路径 - ⚠️ 注意：
//api.example.com和//v2.api.example.com是两个独立 DNS 查询，别漏掉子域
只对“马上真要用”的第三方域名有效
dns-prefetch 不加速首屏 HTML/CSS/JS 加载，只影响后续 JS 发起的 fetch、懒加载图片、字体 CSS 等异步请求。加错对象，反而挤占浏览器 DNS 并发队列（通常限 6～10 个）。
- ✅ 值得加：
//api.example.com（首页卡片数据，DOM ready 后 100ms 内 fetch）、//fonts.googleapis.com（@import 字体 CSS）、//hm.baidu.com（统计 SDK 初始化必调） - ❌ 不该加：
//log.example.com（用户行为上报，可延后）、//your-site.com（同源，DNS 缓存已共享）、//backup-api.example.com（兜底接口，99% 不触发） - ⚠️ 如果目标域名只支持 HTTPS，但当前页是 HTTP，
//写法会降级为 HTTP 导致失败——这种场景应换用<link rel="preconnect" href="https://..." crossorigin>
最容易被忽略的一点：浏览器不保证执行 dns-prefetch，尤其在弱网、内存紧张或高负载时会主动丢弃。它不是“一定生效”的指令，而是“请尽量早点查一下”的轻量提示——所以每个标签都得经得起追问：“这个域名，接下来 300ms 内真的会发请求吗？”
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
