link rel="dns-prefetch" 仅对即将跳转或异步加载的第三方域名有效，如外链、api、cdn 域名，且 href 必须带协议或双斜杠；不适用于已加载域名或无实际用途域名，不可与 preconnect 混用，safari 支持较弱且缓存时间短。
link rel="dns-prefetch" 是最轻量、兼容性最好的前端 DNS 预解析手段，但它只在浏览器支持且资源真正被用到时才生效——不是加了就一定提前解析，也不是所有域名都值得加。
哪些域名适合加 link rel="dns-prefetch"
只对「即将跳转或异步加载」的第三方域名有效，比如：
- 用户点击后会跳转的外链域名（如
https://pay.example.com） - 页面中通过
fetch或XMLHttpRequest主动请求的 API 域名（如https://api.service.com） - CDN 域名（如
https://cdn.yoursite.net），但前提是该 CDN 域名不在当前 HTML 的初始资源（script、img、link）中直接出现
别给当前页面已加载的域名（比如主站 yourdomain.com）加——浏览器已经解析过了；也别给没实际用途的域名加，纯浪费标签和解析队列。
href 值必须带协议或用双斜杠写法
错误写法：<link rel="dns-prefetch" href="example.com">（会被当成相对路径，解析失败）
正确写法只有两种：
-
<link rel="dns-prefetch" href="https://example.com">（推荐，语义明确） -
<link rel="dns-prefetch" href="//example.com">（兼容 HTTP/HTTPS 混合场景，但现代项目基本不用）
注意：浏览器只取 href 中的域名部分做解析，协议、路径、查询参数全被忽略。所以 https://api.example.com/v1/users?x=1 和 https://api.example.com 效果完全一样。
和 preconnect 别混用，也别盲目叠加
dns-prefetch 只做 DNS 查询，不建 TCP 连接、不发 TLS 握手；而 preconnect 会走到 TCP+TLS 阶段，开销大得多。
- 如果后续确定要发起 HTTPS 请求（比如 JS 里马上要
fetch），优先用<link rel="preconnect" href="https://api.example.com">，它隐含了 DNS 预解析 - 如果只是“可能点链接”，且不想提前建立连接（比如怕触发 CORS 预检或暴露用户行为），那就只用
dns-prefetch - 不要同时写两个：
preconnect已覆盖 DNS 解析，重复写没收益，还占 HTML 体积
Chrome/Firefox 支持好，Safari 有延迟或忽略
实测 Safari（macOS/iOS 16+）对 dns-prefetch 的执行时机更保守：常等到页面空闲、甚至用户交互后才真正发起查询，不像 Chrome 那样在 HTML 解析阶段就启动。
如果你的主力用户大量使用 Safari，且对首屏外链跳转速度敏感，得配合其他手段：
- 在用户 hover 链接时用 JS 主动调用
new Image().src = "https://target.com/favicon.ico"（触发 DNS + TCP） - 或者改用
preconnect（Safari 对它的支持更积极）
真正容易被忽略的是：DNS 预解析结果默认只缓存 60–300 秒（各浏览器不同），如果用户停留时间长、又隔了很久才点击，解析可能已过期——这时候预解析就白做了。
