dns-prefetch仅加速后续异步请求的DNS解析，需写对href（仅主机名、双斜杠或HTTPS协议）、放对位置（head中靠前）、选对域名（第三方非同源），且不可与preconnect混用。
rel="dns-prefetch" 不会加速当前页面的首屏资源加载，它只对后续异步请求或跳转中真正用到的第三方域名有效；加错位置、写错格式、滥用域名，反而浪费解析队列，甚至拖慢首屏。
怎么写 href 才不被浏览器忽略
浏览器只提取 href 中的主机名做 DNS 查询，其余部分全被丢弃。写法错误等于没写，且无任何报错提示。
- ✅ 正确：
<link rel="dns-prefetch" href="//fonts.gstatic.com">（双斜杠协议相对，无路径） - ✅ 正确：
<link rel="dns-prefetch" href="https://api.example.com">（显式 HTTPS，现代环境更稳） - ❌ 错误：
<link rel="dns-prefetch" href="http://cdn.example.com">（HTTP 页面可能生效，HTTPS 页面直接跳过） - ❌ 错误：
<link rel="dns-prefetch" href="//cdn.example.com/js/app.js">（含路径，整个标签被忽略） - ❌ 错误：
<link rel="dns-prefetch" href="cdn.example.com">（无协议/双斜杠，被当成本地相对路径处理）
放在 什么位置才真起作用
浏览器是流式解析 HTML 的，dns-prefetch 标签一旦被读到，就立即排队执行。放得太晚，等它被解析时，相关资源请求早已发起。
- ✅ 推荐位置：
<meta charset>和<title>之后、首个<link rel="stylesheet">或<script>之前 - ❌ 无效位置：塞在
<body>里、包裹在<template>中、或由 JS 动态document.createElement('link')插入 - ⚠️ 注意：它不阻塞渲染，但若放在大量 CSS/JS 后面，DNS 查询可能被首屏关键资源抢占调度优先级
哪些域名值得加，哪些纯属浪费
每个 dns-prefetch 都会触发一次独立 DNS 查询，浏览器有并发限制（通常 6～10 个），无效查询既占系统资源，又可能干扰真实请求。
立即学习“前端免费学习笔记（深入）”；
- ✅ 值得加：CDN 域名（
//cdn.example.com）、字体服务（//fonts.googleapis.com）、统计 SDK（//hm.baidu.com）、首屏后立即 fetch 的 API 域（//api.example.com） - ❌ 不该加：当前主站同源域名（
//your-site.com）、未在页面中实际引用的域名、广告联盟等不稳定第三方、用户点击后才跳转的外链（更适合用rel="prefetch"或 hover 时 JS 触发） - ⚠️ 注意：Safari 对
dns-prefetch执行更保守，常延迟到空闲或用户交互后；DNS 缓存默认仅 60–300 秒，长停留后点击仍可能重新查
和 rel="preconnect" 到底能不能一起用
不能。两者目标不同，且 preconnect 已隐含 DNS 解析，重复声明不仅无收益，还白占 HTML 体积和解析队列。
- ✅ 选
preconnect：当你确定几秒内必发 HTTPS 请求（如首屏关键 API、字体文件），且域名支持 CORS（需加crossorigin） - ✅ 选
dns-prefetch：仅需提前解析、不希望提前建连（比如埋点上报、备用 CDN、用户行为不确定的跳转） - ❌ 别混用：
<link rel="dns-prefetch" href="//api.example.com">+<link rel="preconnect" href="https://api.example.com" crossorigin>→ 后者已覆盖前者，前者冗余
最容易被忽略的是：它不保证执行。弱网、内存紧张、浏览器空闲不足时，dns-prefetch 可能被直接跳过——所以只加真正影响核心路径的那两三个域名，比堆十个“以防万一”有用得多。
