仅用于开关浏览器隐式dns预解析全局策略，不指定域名；真正触发特定域名预解析的是，且必须置于和之后、首个外部资源之前，href须为协议相对域名（如//cdn.example.com）。
meta http-equiv="x-dns-prefetch-control" 只能开关全局策略，不能指定域名
这个 meta 标签不是用来“预解析某个域名”的，它只控制浏览器是否启用**隐式 DNS 预解析**（即自动扫描页面中所有跨域链接并提前查 DNS）。它本身不触发任何 DNS 查询，也不声明目标域名。
常见错误是把它和 <link rel="dns-prefetch"> 混用，以为写了 content="on" 就能生效——其实现代浏览器默认就开启隐式预解析，写不写这个标签影响极小；而 content="off" 才有实际作用：禁用自动扫描。
-
content="on"：显式启用（但多数浏览器本就开启，基本等价于不写） -
content="off"：强制关闭隐式预解析，防止浏览器自动查页面里没控制权的第三方链接（如用户生成内容里的<a href="https://evil.com"></a>） - 大小写不敏感，
X-DNS-Prefetch-Control、x-dns-prefetch-control都可，但推荐全小写以兼容旧解析器
想让浏览器提前查特定域名？必须用
<meta http-equiv="x-dns-prefetch-control"> 不负责“查哪个”，真正干活的是 <link rel="dns-prefetch">。这个标签一被 HTML 解析器读到，就会立即排队发起 DNS 查询。
- 位置很关键：必须放在
<meta charset>和<title></title>之后、首个外部资源（如<link rel="stylesheet">或<script src></script>）之前，否则大概率来不及生效 -
href必须是协议相对 URL，仅含主机名，例如：//cdn.example.com或https://fonts.googleapis.com - 写错格式不会报错，但标签静默失效：
href="cdn.example.com"（缺//）、href="//api.example.com/api/v1"（带路径）、href="http://cdn.example.com"（显式 HTTP，在 HTTPS 页面可能被 Safari 跳过）
为什么开了 x-dns-prefetch-control 还没效果？检查这几个坑
很多人加了 <meta http-equiv="x-dns-prefetch-control" content="on"> 却发现 DNS 查询没变多，是因为：
- 浏览器本就不依赖该标签启动隐式预解析——Chrome/Firefox 默认就开，写
on是冗余操作 - 你真正想预查的域名根本没用
<link rel="dns-prefetch">声明，光开开关没用 - 标签放错位置：插在
<script></script>后面、里、或用 JS 动态创建，这些都不会触发查询 - Safari 行为更保守：即使写了
<link rel="dns-prefetch">，也可能延迟到空闲或用户交互后才执行，所以位置越靠前越好
移动端和高并发场景下要特别注意数量和选择
每个 <link rel="dns-prefetch"> 都是一次真实 DNS 查询，浏览器并发上限通常只有 6～10 个。无效请求不仅浪费资源，还可能挤占首屏关键请求的调度队列。
- 只加确定会在首屏后 1–2 秒内使用的跨域域名，例如：
//api.example.com（首屏后立即fetch）、//hm.baidu.com（统计 SDK 初始化必发） - 不要加同源或子域：
//your-site.com、//admin.example.com—— DNS 缓存已共享，纯属浪费 - 避免加不稳定或常被拦截的域名：
//ad.doubleclick.net—— 查询失败仍计数，并可能触发隐私拦截器告警 - 移动端建议总数控制在 3–5 个以内，过多反而拖慢首屏解析
http-equiv 开关，而在 <link rel="dns-prefetch"> 是否存在、是否写对、是否放对位置——这三个条件缺一不可。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
