dns-prefetch必须置于<head>靠前位置，即<meta charset>和<title>之后、首个<link rel="stylesheet">或<script>之前；href须为//开头的协议相对域名（如//cdn.example.com），不可带路径、端口或协议头；仅对后续确有请求的第三方跨域域名有效，同源或无效域名会浪费DNS并发队列；与preconnect混用同一域名时后者覆盖前者。
dns-prefetch 标签写在哪儿才真正起作用
它必须出现在 <head> 里，且越靠前越好——理想位置是 </meta charset> 和 <title> 之后、首个 <link rel="stylesheet"> 或 <script> 之前。浏览器流式解析 HTML，一读到这个标签就排队做 DNS 查询；塞在 <body> 里、用 JS 动态插入、或包在 <template> 中，全都不生效。
href 值怎么写才不被浏览器忽略
必须是协议相对写法，即以 // 开头，后面只跟域名，不能带路径、端口、查询参数或协议头：
- ✅ 正确：
<link rel="dns-prefetch" href="//cdn.example.com"> - ✅ 正确：
<link rel="dns-prefetch" href="//fonts.googleapis.com"> - ❌ 错误：
<link rel="dns-prefetch" href="https://cdn.example.com/js/app.js">（含路径） - ❌ 错误：
<link rel="dns-prefetch" href="http://api.example.com:3000">（显式协议+端口） - ⚠️ 注意：
//写法在 HTTP 页面中会降级为 HTTP，在 HTTPS 页面中升为 HTTPS；若目标域名只支持 HTTPS（如多数现代 CDN），而你当前页是 HTTP，这种场景应改用<link rel="preconnect">并加crossorigin
哪些域名值得加，哪些纯属浪费
每个 dns-prefetch 都是一次真实 DNS 查询，浏览器并发上限通常为 6～10 个。加错对象，反而挤占关键请求的资源调度优先级：
- ✅ 值得加：
//cdn.example.com（图片/JS/CSS 真实加载）、//api.example.com（首屏后立即 fetch）、//hm.baidu.com（统计 SDK 初始化必发） - ❌ 不该加：
//your-site.com（同源，DNS 已缓存）、//ad.doubleclick.net（广告常被拦截、不稳定）、//admin.example.com（子域共享主域 DNS 缓存） - ⚠️ 不支持通配符：
//*.example.com无效；也不必为cdn1和cdn2分别加，除非它们由不同权威 DNS 管理
和 preconnect 混用同一域名会怎样
不会叠加效果，只会白写一个：
立即学习“前端免费学习笔记（深入）”；
-
dns-prefetch只做 DNS 解析，开销极低；preconnect会继续走 TCP 握手 + 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">同时存在
最易被忽略的点：它不保证执行。弱网、内存紧张、隐私模式（如 uBlock Origin 默认禁用）、或服务端设置了 X-DNS-Prefetch-Control: off，都会让它静默失效——别只看代码写了没，得去 Chrome DevTools 的 Network → Timing 里确认 DNS 查询是否真的提前了。
