dns-prefetch 必须用 写在 最前面， 标签无效；href 需以 // 开头且仅含域名；只预解析确定会用的第三方域名，不保证执行。
dns-prefetch 不是 meta 标签，而是 link 标签的 rel 值。所有把 DNS 预解析写成 <meta rel="dns-prefetch"> 或类似变体的用法，浏览器直接忽略，且不报错——你根本看不到效果。
为什么不能用 meta 标签写 dns-prefetch
浏览器只识别 <link rel="dns-prefetch"> 这一种语法。W3C 规范和所有主流引擎（Chrome、Firefox、Safari、Edge）都只在 link 元素上实现该行为。meta 的 name 和 http-equiv 属性根本不支持 dns-prefetch 语义，写进去等于注释。
-
<meta http-equiv="x-dns-prefetch-control" content="on">是合法的，但它只是开关全局预解析策略，不是声明具体域名 -
<meta name="dns-prefetch" content="//cdn.example.com">—— 无效，浏览器无视 - 混淆
meta和link是新手最常踩的坑，查半天 Network 面板没记录，其实是标签压根没被解析
href 必须以 // 开头，且仅含域名
浏览器只从 href 中提取主机名，其余全丢弃。格式错一点，整个 link 就静默失效。
- ✅ 正确：
<link rel="dns-prefetch" href="//cdn.example.com"> - ✅ 可接受（现代环境更稳）：
<link rel="dns-prefetch" href="https://fonts.googleapis.com"> - ❌ 错误：
<link rel="dns-prefetch" href="https://cdn.example.com/js/app.js">（含路径） - ❌ 错误：
<link rel="dns-prefetch" href="cdn.example.com">（缺//，被当成本地相对路径） - ❌ 错误：
<link rel="dns-prefetch" href="http://api.example.com">（HTTPS 页面中会被 Safari 等跳过）
必须放在
浏览器流式解析 HTML，dns-prefetch 一读到就排队执行。放晚了，首屏 JS/CSS 请求早就发出去了，预解析完全来不及。
立即学习“前端免费学习笔记（深入）”；
- ✅ 理想顺序：
<meta charset>→<title></title>→<link rel="dns-prefetch">× N →<link rel="stylesheet">或首个<script></script> - ❌ 无效位置：塞在
里、包裹在<template></template>中、用 JS 动态创建并插入（document.createElement('link')） - ⚠️ 注意：它不阻塞渲染，但若放在大量 CSS 后面，DNS 查询可能被首屏关键请求抢占调度优先级
只加确定会用的第三方域名，别碰同源和备用链
每个 dns-prefetch 都触发一次真实 DNS 查询，浏览器并发上限通常为 6～10 个。无效查询不仅白耗系统资源，还可能挤占真实请求的队列。
- ✅ 值得加：
//cdn.example.com（图片/JS/CSS 实际托管地址）、//api.example.com（首屏后立即 fetch 的接口）、//hm.baidu.com（统计 SDK 初始化必发） - ❌ 不该加：
//example.com（同源，DNS 已缓存）、//ad.example.com（广告联盟不稳定，常被拦截或延迟加载）、//backup-cdn.example.com（实际未启用，纯属“以防万一”） - ⚠️ 注意：
//fonts.googleapis.com和//fonts.gstatic.com是两个独立域名，不能互相替代；也不支持通配符，//*.example.com无效
最容易被忽略的是：它不保证执行。Safari 对 dns-prefetch 执行更保守，常延迟到空闲或用户交互后；DNS 缓存默认仅 60–300 秒，用户长时间停留后点击仍可能重新查。所以别指望它解决所有延迟，只把它当作「对已知高频跨域域名的轻量探路」——多一个不多，错一个白忙。
