dns-prefetch不能提升并发数，但可降低单个跨域请求DNS耗时20–120ms（弱网达150ms+）；它仅提前完成DNS解析，不建立连接，需正确写在靠前位置、href仅含协议相对域名，否则静默失效。
dns-prefetch 在高并发外部请求下真能提速吗
不能直接提升并发数，但能降低单个跨域请求的 DNS 环节耗时——典型收益是 20–120ms，弱网下可达 150ms+。它不增加浏览器并发上限（通常 DNS 查询队列仅 6～10 个），只把原本串行的「DNS → TCP → TLS」拆开，提前干掉第一个环节。
这意味着：如果你页面要同时加载 8 个不同 CDN 域名的资源（比如 //cdn1.example.com、//img0.example.com、//fonts.googleapis.com），而只对其中 3 个加了 ，那这 3 个资源的 DNS 阶段大概率会提前完成；其余 5 个仍得等真正发起请求时才查 DNS，可能被阻塞在队列里。
- 浏览器不会为每个
dns-prefetch开新线程，而是统一调度进有限 DNS 查询池 - 加太多反而挤占关键请求的调度优先级，尤其在内存紧张或弱网设备上，浏览器可能跳过部分预解析
- 实测要看单个资源的 Timing 面板中 DNS Lookup 是否出现在页面加载早期，而不是对比整页 TTFB 或 FCP
href 写错就等于没写，且完全静默失效
浏览器提取 href 时只认协议相对域名（//cdn.example.com），其余全丢弃，且不报任何错误。这是线上环境最常漏查的问题。
- ❌
https://cdn.example.com：HTTPS 页面可能被跳过，旧版 Safari 尤其敏感 - ❌
//cdn.example.com/js/app.js：含路径，整个标签被忽略 - ❌
cdn.example.com：缺//，被当成本地路径处理 - ✅
//cdn.example.com：推荐写法，适配当前页协议 - ✅
https://fonts.googleapis.com：仅限 HTTPS 页面，更稳但兼容性略窄
特别注意：//fonts.googleapis.com 和 //fonts.gstatic.com 是两个独立域名，必须分别声明，不能靠通配符（//*.googleapis.com 无效）。
放在哪儿才算“来得及”
必须塞进 ，且要在首个依赖它的外部资源标签之前——越早越好，晚了就白加。
- ✅ 推荐位置：
和或<script src></script>之前 - ❌ 无效位置：塞在
里、包在中、用 JS 动态创建并插入（document.createElement('link')） - ⚠️ 即使放对位置，若前面有大量阻塞渲染的 CSS/JS，DNS 查询也可能被延迟调度，Safari 更倾向等到空闲或用户交互后才执行
哪些域名值得加，哪些纯属浪费
只对「确定会在页面生命周期中真实发出请求」的第三方跨域域名有效。同源域名、未触发的懒加载目标、广告联盟等不稳定域名，加了反而拖慢首屏。
- ✅ 值得加：
//cdn.example.com（图片/JS/CSS 真实加载）、//api.example.com（首屏后立即fetch()）、//hm.baidu.com（统计 SDK 初始化必发） - ❌ 不该加：
//your-site.com（同源，DNS 已缓存）、//ad.doubleclick.net（常被拦截、不可控）、//admin.example.com（子域共享主域 DNS 缓存） - ⚠️ 多域 CDN 场景下，
cdn1.example.com和cdn2.example.com是两次独立查询，但若它们共用同一套权威 DNS，加一个就够了；若分属阿里云 + Cloudflare，则需分别加
真正容易被忽略的是：这个优化只在「首次访问且 DNS 缓存未命中」时生效。缓存命中时 Timing 面板里 DNS 时间为 0，不是失效，是它本就不需要工作。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
