能，但仅对后续异步请求生效，需满足域名真实被请求、href格式正确（协议相对域名）、标签置于靠前位置三个硬条件。
dns-prefetch 在多域 CDN 场景下真能加速吗
能，但只对「后续异步请求」生效，且必须满足三个硬条件：域名真实被请求、href 写对、标签位置靠前。它不加速首屏已声明的 <script src></script> 或 <img src>，只影响 JS 中动态 fetch 的图片、懒加载模块、字体 CSS 加载后的 @font-face 请求等。
比如你用多个 CDN 域名：//cdn1.example.com（主 JS/CSS）、//img0.example.com（图片）、//fonts.example.com（自托管字体），只要这些域名在页面生命周期中被 JS 或 CSS 显式引用，dns-prefetch 就能提前把 DNS 查询做完——省掉 100–300ms 的等待时间。
- 浏览器并发 DNS 查询数有限（通常 6～10 个），多域 CDN 意味着你要精确选最关键的 2～3 个，不能全加
- 子域之间不共享 DNS 缓存（
cdn1.example.com和cdn2.example.com是两次独立查询） - 如果 CDN 域名背后是同一套权威 DNS，加一个就够了；但如果分属不同云厂商（如阿里云 CDN + Cloudflare CDN），就得分别加
href 怎么写才让多域 CDN 都生效
href 必须是纯协议相对域名，不含路径、端口、协议头。写错格式浏览器直接静默丢弃，控制台零报错——这是最常踩的坑。
- ✅ 正确：
<link rel="dns-prefetch" href="//cdn1.example.com">、<link rel="dns-prefetch" href="//img0.example.com"> - ❌ 错误：
<link rel="dns-prefetch" href="https://cdn1.example.com/js/app.js">（含路径，整个标签失效） - ❌ 错误：
<link rel="dns-prefetch" href="cdn1.example.com">（缺//，被当成本地路径解析） - ⚠️ 注意：如果当前页是 HTTP，而
//fonts.example.com只支持 HTTPS，DNS 查询虽成功，但后续请求会因协议降级失败——这种场景应改用preconnect并声明crossorigin
放在哪儿才算真正起作用
必须塞进 里，且要在首个外部资源（比如第一个 <link rel="stylesheet">）之前。浏览器流式解析 HTML，看到 dns-prefetch 就立刻排队，晚了就来不及。
- ✅ 推荐顺序：
<meta charset>→<title></title>→<link rel="dns-prefetch">× N →<link rel="stylesheet"> - ❌ 无效位置：
里、<template></template>中、JS 动态创建后document.head.appendChild() - ⚠️ 即使位置正确，若页面顶部堆了大量阻塞渲染的 CSS/JS，DNS 查询也可能被调度延迟——Safari 尤其保守，常等到空闲或用户交互后才执行
和 preconnect 混用多域 CDN 时怎么选
别混用同一域名。浏览器遇到 preconnect 会直接忽略同域名的 dns-prefetch，后者纯属冗余。
- 对确定高频且支持 HTTPS 的 CDN 域名（如字体服务
//fonts.example.com），优先用<link rel="preconnect" href="https://fonts.example.com" crossorigin> - 对“可能用到”的备用 CDN（如
//cdn-backup.example.com）、统计上报域名（//stats.example.com），用dns-prefetch更稳妥——开销低，不抢占 TCP 连接数 - 如果 CDN 域名只提供静态资源（图片/JS），且首次请求发生在用户滚动后（懒加载），
dns-prefetch是唯一合理选择；preconnect过早建连反而浪费连接池
多域 CDN 环境下，真正容易被忽略的是域名粒度控制：不是“所有 CDN 都加”，而是“哪个 CDN 资源在哪个时机被哪个逻辑触发”。漏掉一次 JS 动态 fetch 的域名，或者多加一个广告联盟的无效域名，效果就打对折。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
