dns-prefetch 的 href 必须为 //domain.com 或 https://domain.com，仅提取主机名做 DNS 查询；须置于 head 中 meta charset 和 title 后、首个外部资源前；只预解析首屏后立即使用的跨域域名，避免与 preconnect 混用同一域名。
dns-prefetch 的 href 必须写成 //domain.com 才生效
浏览器只从 href 中提取主机名做 DNS 查询，其余内容全被丢弃，且不报任何错误——写错就等于没写，但你根本查不到。常见错误包括：https://cdn.example.com/js/app.js（含路径）、cdn.example.com（缺 //）、http://api.example.com（HTTPS 页面下大概率跳过）。
✅ 正确写法只有两种：<link rel="dns-prefetch" href="//cdn.example.com">（推荐，协议自动适配）；<link rel="dns-prefetch" href="https://fonts.googleapis.com">（HTTPS 页面更稳，避免降级风险）。
⚠️ 注意：// 写法在 HTTP 页面会降级为 HTTP；若目标域名仅支持 HTTPS（如多数现代 CDN），而当前页是 HTTP，则应改用 <link rel="preconnect"> 并声明 crossorigin。
必须放在 <head> 里 meta charset 和 title 之后、首个外部资源之前
浏览器流式解析 HTML，<link rel="dns-prefetch"> 一被读到就立即排队执行 DNS 查询。如果它出现在 <link rel="stylesheet"> 或 <script src> 后面，首屏资源请求大概率已经发出，预解析完全来不及生效。
立即学习“前端免费学习笔记（深入）”；
✅ 推荐顺序：<meta charset> → <title> → 所有 <link rel="dns-prefetch"> → 首个 <link rel="stylesheet"> 或 <script>
❌ 无效位置：塞在 <body> 里、包在 <template> 中、或用 JS 动态插入（如 document.createElement('link')）——这些都不会触发任何 DNS 查询。
⚠️ Safari 更保守，若前面堆了大量 CSS/JS，DNS 查询可能被首屏关键资源抢占调度优先级，甚至延迟到空闲时才执行。
只加确定会在首屏后立即请求的第三方跨域域名
dns-prefetch 不加速首屏资源，只影响 JS 中 fetch、懒加载图片、字体 CSS 加载等后续异步请求。每个标签都是一次真实 DNS 查询，浏览器并发上限通常为 6～10 个。
✅ 值得加：//cdn.example.com（首屏图片/JS 真实加载）、//api.example.com（DOM ready 后 100ms 内发起 fetch）、//hm.baidu.com（统计 SDK 初始化必调）
❌ 不该加：//your-site.com（同源，DNS 已缓存）、//admin.example.com（子域共享主域 DNS 缓存）、//ad.doubleclick.net（广告常被拦截，不稳定）
⚠️ 不支持通配符：//*.example.com 无效；也不必为 cdn1 和 cdn2 分别加，除非它们由不同权威 DNS 管理且都被首屏资源明确引用。
别和 preconnect 混用同一域名
dns-prefetch 只做 DNS 解析；preconnect 会进一步建连 + TLS 握手，开销更大但收益更高。浏览器对同一域名同时看到两者时，preconnect 会直接覆盖 dns-prefetch，后者被忽略。
✅ 推荐组合：<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>（确定高频用） + <link rel="dns-prefetch" href="//metrics.example.com">（仅可能上报）
❌ 避免：<link rel="dns-prefetch" href="//cdn.example.com"> 和 <link rel="preconnect" href="//cdn.example.com"> 同时存在——白写一个，还浪费队列。
真正难的是判断“是否真会用”：不是页面里写了域名就算，而是得确认 JS 在 DOM ready 后极短时间内确实发出了对应请求。否则，这个标签就是隐形拖慢项。
