dns-prefetch 必须置于 和 之后、首个外部资源标签之前，否则因浏览器流式解析而失效；仅支持协议+域名格式，错误格式无报错但无效；应精准选择确定使用的跨域域名，避免与 preconnect 混用同一域名。
dns-prefetch 必须放在
最前面，否则无效
浏览器是流式解析 HTML 的， 一旦被读到就立即排队执行；如果它出现在首个 或 <script></script> 之后，很可能首屏资源请求已发出，预解析根本来不及生效。
- ✅ 正确位置：
和 - ❌ 错误做法：塞在
里、用 JS 动态document.createElement('link')插入、包裹在中 - ⚠️ Safari 更保守，常延迟到空闲或用户交互后才执行；放太晚，可能被首屏 CSS/JS 抢占调度优先级
href 只能写协议+域名，路径和端口会导致整个标签被忽略
dns-prefetch 只提取 href 中的主机名做 DNS 查询，其余内容全被丢弃。写错格式不会报错，但等于没写——你检查控制台也看不到任何提示。
- ✅ 合法写法：
、 - ❌ 非法写法：
href="https://cdn.example.com/js/app.js"（含路径）、href="cdn.example.com:8080"（显式端口）、href="http:/cdn.example.com"（协议拼错） - ⚠️
//fonts.gstatic.com和//fonts.googleapis.com是两个独立域名，不能互相替代；也不支持通配符，//*.example.com无效
只加确定会用的第三方跨域域名，同源或子域通常不用
每个 dns-prefetch 都是一次真实 DNS 查询，浏览器并发上限通常为 6～10 个。无效查询既占系统资源，又可能干扰真实请求优先级。
- ✅ 值得加：
//cdn.example.com（首屏图片/JS/CSS 真实加载）、//api.example.com（首屏后立即fetch）、//hm.baidu.com（统计 SDK 初始化必发） - ❌ 不该加：
//your-site.com（同源，DNS 缓存已共享）、//admin.example.com（子域共享主域缓存）、//ad.doubleclick.net（广告联盟不稳定、常被拦截） - ⚠️ 别为
cdn1.example.com和cdn2.example.com分别加，除非它们由不同权威 DNS 管理；也不必凑数加备用 CDN 或懒加载模块所用域名
别和 preconnect 混用同一域名，否则后者覆盖前者
dns-prefetch 只做 DNS 解析，开销极低；preconnect 会进一步建 TCP 连接 + TLS 握手，资源占用高且受并发限制（通常最多 6 个）。两者目的不同，混用不仅冗余，还可能浪费连接资源。
- ✅ 同一域名只选一个：
preconnect更激进，适合确定高频使用且支持 HTTPS 的域名（如字体服务）；dns-prefetch更稳妥，适合“可能用到”或“用户触发后才发请求”的场景 - ❌ 同时写两者：
preconnect会覆盖dns-prefetch，后者被忽略，纯属冗余 - ⚠️ 如果当前页是 HTTPS，但写了
http://，该标签大概率被跳过；//在 HTTP 页面中会降级为 HTTP，可能失败——这种场景应改用preconnect并声明crossorigin
实际生效与否，取决于你是否在用户真正发起请求前，把域名“塞进浏览器的 DNS 查询队列”。很多团队加了但没效果，问题往往出在位置、格式或域名选择上，而不是技术本身不工作。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
