应只加真正影响首屏的2～3个CDN域名，如//img0.cdn.com和//js.cdn.com；多余dns-prefetch会被静默丢弃，且需协议相对写法、置于head中meta/title后script前，避免与preconnect混用。
dns-prefetch 在多域 CDN 场景下到底该加几个
加太多反而拖慢首屏——浏览器对 dns-prefetch 的并发执行数有硬限制，通常为 6～10 个，超出部分会被静默丢弃或延迟调度。多域 CDN（如 //img0.cdn.com、//img1.cdn.com、//js.cdn.com、//fonts.cdn.com）看似要全加，实际只应保留真正影响首屏加载的那几个。
常见错误是把所有 CDN 子域都列一遍，结果前 3 个没被解析完，后 4 个根本没触发。
- 优先保
//img0.cdn.com和//js.cdn.com：首屏图片和关键 JS 很可能从这两域加载 - 舍弃
//img2.cdn.com或//backup.cdn.com：除非你明确在首屏 JS 中做了new Image().src = "https://img2.cdn.com/..."这类主动请求，否则它属于“备用路径”，不值得占队列 - 注意
//fonts.cdn.com和//fonts.googleapis.com是两个独立域名，不能互相替代；但若你只用 Google Fonts，就别再加自家字体 CDN - 同一主域下的多个子域（如
cdn1.example.com和cdn2.example.com）是否都要加？仅当它们由不同权威 DNS 管理、且实际被首屏资源分别引用时才加；否则 DNS 缓存可共享，加一个就够了
href 写 //img0.cdn.com 还是 https://img0.cdn.com？
必须用双斜杠协议相对写法：//img0.cdn.com。显式写 https:// 在旧版 Safari（尤其是 iOS 15 之前）中大概率被跳过；写 http:// 在 HTTPS 页面里直接失效，控制台还可能报混合内容警告。
协议相对写法让浏览器自动补全当前页协议，兼容性更稳，也避免中间代理或 CDN 边缘节点误判。
立即学习“前端免费学习笔记（深入）”；
- ✅ 正确：
<link rel="dns-prefetch" href="//img0.cdn.com"> - ❌ 错误：
<link rel="dns-prefetch" href="https://img0.cdn.com">（Safari 忽略） - ❌ 错误：
<link rel="dns-prefetch" href="//img0.cdn.com/logo.png">（含路径，整个标签被静默忽略） - ⚠️ 注意：
//img0.cdn.com:443这种带端口的写法无效，DNS 解析不关心端口
为什么加了 dns-prefetch，DevTools 里 DNS Lookup 时间没变短
不是代码没生效，而是浏览器压根没执行——最常见原因是位置放错了。DNS 预解析依赖 HTML 流式解析时机，它必须在浏览器遇到第一个跨域资源请求前就被读到。
- ✅ 正确位置：
<meta charset>和<title>之后、首个<script src="https://...">或<link rel="stylesheet" href="https://...">之前 - ❌ 错误位置：塞在
<body>里、包在<template>中、或用 JS 动态创建并 append（document.head.appendChild(link)）——这些都不会触发预解析 - ⚠️ 验证方法：打开 Chrome DevTools → Network → 找任意一个跨域请求 → Timing 标签页里看 “DNS Lookup” 是否明显早于 “Initial connection”。如果仍是灰色或为 0ms，说明 DNS 已缓存；如果始终没提前，大概率是标签没被识别或位置太晚
- ? 小技巧：在本地用
chrome://net-internals/#dns清空 DNS 缓存后重刷，能更真实观察效果
dns-prefetch 和 preconnect 能不能一起用在同一个 CDN 域名上
不能。浏览器看到同一域名同时存在 dns-prefetch 和 preconnect，会直接忽略前者，只执行后者。而 preconnect 开销远高于 dns-prefetch：它要建 TCP 连接 + 完成 TLS 握手，受浏览器并发连接数限制（通常最多 6 个），还会占用 socket 资源。
- ✅ 推荐组合：对高频、确定必用、支持 HTTPS 的 CDN 域名（如字体服务），直接上
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> - ✅ 对低频、异步加载、或只用于埋点上报的 CDN 域名（如
//log.cdn.com），用dns-prefetch更稳妥 - ❌ 同时写两者：
<link rel="dns-prefetch" href="//img0.cdn.com"><link rel="preconnect" href="https://img0.cdn.com">—— 后者生效，前者白写，还多发一次解析请求 - ⚠️ 特别注意：
preconnect必须显式声明crossorigin（即使目标资源本身没配 CORS），否则在多数现代浏览器中会被降级为普通连接，失去预连意义
dns-prefetch 都是一次真实 DNS 查询，不是免费午餐。留出 2～3 个 slot 给未来可能引入的关键第三方，比堆满 8 个已知域名更可持续。 
