必须写为显式 https 协议（非 //），置于 靠前位置，仅对后续真实使用的跨域域名有效；错误格式、位置靠后或冗余添加均静默失效，且不报错。
HTML里怎么用 dns-prefetch 提前解析域名
直接加 <link rel="dns-prefetch" href="https://cdn.example.com"> 到 里，浏览器就会在空闲时提前做 DNS 查询，等真正请求资源时跳过等待。它不发起 HTTP 请求，只查 IP，开销极小。
常见错误是写成 href="//cdn.example.com"（协议相对），这会导致解析失败；必须带协议（https:// 或 http://）才能生效。另外，别堆太多——一般控制在 3～5 个关键域名内，比如 CDN、API 域名、字体服务，多了反而挤占预连接资源。
为什么 dns-prefetch 比靠浏览器自动缓存更可靠
浏览器确实会缓存 DNS 结果，但缓存时间短（通常 1～5 分钟）、不可控，且只对“已访问过的域名”有效。而 dns-prefetch 是主动触发，哪怕用户第一次打开页面，也能让关键域名的 DNS 在渲染 HTML 阶段就准备好。
使用场景很明确：页面里确定要加载的跨域资源（如 https://fonts.googleapis.com、https://img.example-cdn.com），但又不想等到 <link> 或 <script></script> 解析执行时才开始查 DNS。
注意它和 preconnect 的区别：dns-prefetch 只做 DNS 解析；preconnect 会进一步建立 TCP 连接甚至 TLS 握手——后者开销大，滥用可能拖慢首屏。
dns-prefetch 和 HTTP 缓存头没任何关系，别混用
有人试图给 HTML 响应头加 Cache-Control: max-age=3600 来“提升 DNS 效果”，这是无效的。DNS 缓存由操作系统、本地 DNS 解析器、浏览器各自维护，和 HTTP 响应头完全无关。
真正影响 DNS 行为的只有三类东西：dns-prefetch 标签、preconnect 标签、以及浏览器实际发出的请求触发的隐式解析。其他如 meta http-equiv、Service Worker、CDN 缓存策略，对 DNS 解析过程零干预。
容易被忽略的一点：如果页面用了 CSP（Content Security Policy），且策略里没放行对应域名的 connect-src，某些浏览器（如 Safari）会静默忽略 dns-prefetch，连控制台都不报错。
验证 dns-prefetch 是否生效的最简方式
打开 Chrome DevTools → Network 面板 → 点右上角三个点 → “More tools” → “DNS prefetch cache”，能看到已触发的域名列表。或者在 Performance 面板录制一次加载，过滤关键词 dns，找 DNSResolve 事件。
别依赖“页面变快了”来判断——DNS 节省的时间通常只有 20～100ms，受网络环境影响极大。真要压测效果，得用 WebPageTest 对比开启/关闭时的 domainLookupStart～domainLookupEnd 差值。
最后提醒一句：移动端弱网下，dns-prefetch 的收益最明显；但在 localhost 或局域网开发时，基本测不出差别，因为本机 DNS 查询几乎不耗时。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
