能，dns-prefetch 可加速跨源 API 域名解析，前提是目标域名未被缓存且为真实后续请求；它仅提前解析 DNS，不建连、不发请求，需写为 并置于 靠前位置。
什么是 dns-prefetch，它真能加速 API 域名解析？
能，但有前提：目标域名必须是跨源（cross-origin）的 API 接口地址，且浏览器尚未缓存其 DNS 记录。dns-prefetch 本质是提前触发 DNS 查询，不建立 TCP 连接、不发 HTTP 请求，只解析域名到 IP。对同源请求无效（浏览器已内置优化），对已解析过的域名也无额外收益。
典型适用场景是：前端调用 https://api.example.com（非当前页面域名），且该接口在首屏后不久就要发起请求。
怎么写 link 标签才生效？
必须满足三个硬性条件，缺一不可：
-
<link rel="dns-prefetch" href="https://api.example.com"> 必须放在 <meta charset> 后）
-
href 值必须是完整协议 + 域名（如 https://api.example.com），不能只写 //api.example.com 或 api.example.com
- 浏览器需支持该特性（Chrome、Edge、Firefox、Safari 14+ 都支持；IE 完全不支持）
<link rel="dns-prefetch" href="https://api.example.com"> 必须放在 <meta charset> 后）href 值必须是完整协议 + 域名（如 https://api.example.com），不能只写 //api.example.com 或 api.example.com
常见错误写法：<link rel="dns-prefetch" href="//api.example.com"> —— 协议相对 URL 不被识别；<link rel="dns-prefetch" href="api.example.com"> —— 缺少协议，会被当作相对路径处理。
和 preconnect 有什么区别？什么时候该选哪个？
dns-prefetch 只做 DNS 解析；preconnect 会进一步建立 TCP 连接 + TLS 握手（如果用 HTTPS）。后者开销更大，但收益更高——尤其当 API 请求紧随其后时。
推荐策略：
- 如果 API 请求在页面加载后 1–2 秒内发出 → 用
<link rel="preconnect" href="https://api.example.com"> - 如果只是“可能用到”，或不确定是否真会调用 → 用
dns-prefetch更轻量 - 不要同时写两者：浏览器会对同一域名去重，但写重复没意义，还占 HTML 体积
注意：preconnect 在低带宽或高延迟网络下可能浪费资源（比如用户最终没触发请求），而 dns-prefetch 几乎无副作用。
立即学习“前端免费学习笔记（深入）”；
怎么验证它有没有起作用？ 打开 Chrome DevTools → Network 标签页 → 点击任意请求 → 查看 Timing 选项卡。如果 DNS 解析时间（DNS Lookup）明显低于其他未预解析的跨源请求，说明生效。
更直接的方式是过滤请求列表，找 Initiator 列为 Other 且 Name 是目标域名的条目——这代表浏览器主动发起的 DNS 查询（非真实请求）。也可在 Console 中执行 performance.getEntriesByName("https://api.example.com")，若返回空数组，说明没触发；若有 entry 且 entryType === "navigation" 并含 DNS 时间，则大概率已工作。
别忘了检查实际效果：DNS 解析节省的时间通常在 20–200ms，对整体首屏影响微弱，但它确实能削平“第一次 API 调用”的延迟尖峰——这点在监控 P95 延迟时容易被忽略。
