必须用 // 开头、仅含主机名、置于 最前，仅预解析确定使用的第三方域名，避免与 preconnect 混用，且需通过 devtools 或 chrome://net-internals 验证生效。
在文档解析阶段预解析第三方域名">
href 必须用 // 开头，不能带协议或路径
浏览器只从 href 中提取主机名做 DNS 查询，其余部分全被忽略。写错格式，<link rel="dns-prefetch"> 就等于没写，而且不会报错，极难排查。
-
//cdn.example.com✅ 正确：协议相对，适配当前页 HTTP/HTTPS -
https://cdn.example.com❌ 错误：显式 HTTPS，在旧版 Safari 中常被跳过 -
//cdn.example.com/js/app.js❌ 错误：含路径，整个<link>被静默忽略 -
cdn.example.com❌ 错误：缺协议标识，被当成本地相对路径处理
特别注意：//fonts.googleapis.com 和 //fonts.gstatic.com 是两个独立域名，必须分别声明，不能省略子域。
必须放在 最前面，早于所有外部资源
<link rel="dns-prefetch"> 是流式解析触发的，一旦被 HTML 解析器读到就立即排队执行 DNS 查询。放晚了，相关请求早就发出去了，预解析白做。
- ✅ 理想位置顺序：
<meta charset>→<title></title>→<link rel="dns-prefetch">× N → 首个<link rel="stylesheet">或<script></script> - ❌ 无效位置：丢在
里、塞进<template></template>、用 JS 动态插入（如document.createElement('link')）
它不阻塞渲染，但若排在大量 CSS/JS 后面，DNS 查询可能被首屏关键资源抢占调度优先级。
只加确定会用的第三方域名，别碰同源和备用域名
每个 dns-prefetch 都是一次真实 DNS 查询，浏览器并发上限通常为 6～10 个。无效查询不仅浪费系统资源，还可能挤占真实请求的调度优先级。
- ✅ 值得加：
//cdn.example.com（图片/JS/CSS 真实加载）、//api.example.com（首屏后立即发起的fetch）、//hm.baidu.com（统计脚本初始化必调） - ❌ 不该加：
//your-site.com（同源，浏览器已缓存）、//service.qq.com（仅用户点击才跳转，更适合rel="prefetch"） - ⚠️ 注意：
//*.example.com无效；cdn1.example.com和cdn2.example.com若由不同权威 DNS 管理，才需分别加
别和 preconnect 混用同一域名
dns-prefetch 只做 DNS 解析，开销极低；preconnect 会进一步建 TCP 连接 + TLS 握手，资源占用高，且受浏览器并发限制（通常最多 6 个）。
- ✅ 同一域名只选一个：
preconnect更激进，适合确定高频使用且支持 HTTPS 的域名（如字体服务） - ✅ “可能用到”或“用户触发后才发请求”的场景，用
dns-prefetch更稳妥 - ❌ 同时写两者：
preconnect会覆盖dns-prefetch，后者被忽略，纯属冗余
验证是否生效不能光看代码写了就以为起作用：打开 Chrome DevTools → Network 面板 → 筛选 Other 类型，找带有 domainlookup 字段的条目；或者访问 chrome://net-internals/#dns 搜索目标域名，确认是否出现在缓存列表里。
