<link rel="dns-prefetch"> 不提速首屏，仅对后续异步跨域请求有效；href须为//开头纯域名或HTTPS完整URL，位置需在首个CSS/JS前，仅适用于高频第三方跨域域名，与preconnect不可混用。
加 <link rel="dns-prefetch"> 本身不提速首屏，只对后续异步请求的跨域域名有效；写错 href、放错位置、加错域名，不仅没收益，还可能拖慢关键请求。
href 必须是 // 开头的纯主机名，否则浏览器静默忽略
浏览器只从 href 中提取主机名做 DNS 查询，其余内容全被丢弃，且不报任何错误——你根本查不到它失效了。
- ✅ 正确：
<link rel="dns-prefetch" href="//cdn.example.com">（协议相对，安全兼容） - ✅ 正确：
<link rel="dns-prefetch" href="https://fonts.googleapis.com">（HTTPS 页面显式写法更稳） - ❌ 错误：
<link rel="dns-prefetch" href="https://cdn.example.com/js/app.js">（含路径，整个标签被忽略） - ❌ 错误：
<link rel="dns-prefetch" href="cdn.example.com">（无协议标识，被当成本地路径处理） - ⚠️ 注意：
http://写法在 HTTPS 页面大概率被跳过；//在 HTTP 页面会降级为 HTTP，若目标只支持 HTTPS，则应改用preconnect并声明crossorigin
必须放在 靠前位置，晚于首个 CSS/JS 就基本失效
浏览器流式解析 HTML，<link rel="dns-prefetch"> 一旦被读到就立即排队执行。如果它出现在第一个 <link rel="stylesheet"> 之后，相关资源请求往往已经发出了。
- ✅ 推荐位置：
<meta charset>和<title>之后、首个<link rel="stylesheet">或<script>之前 - ❌ 无效位置：塞在
<body>里、包裹在<template>中、或由 JS 动态插入（如document.createElement('link')） - ⚠️ 它不阻塞渲染，但若排在大量阻塞资源后，DNS 查询可能被调度延迟；Safari 更保守，常等到空闲或用户交互后才执行
只对确定高频使用的第三方跨域域名有效，同源或低频域名纯属浪费
每个 dns-prefetch 都是一次真实 DNS 查询，浏览器并发上限通常为 6～10 个。无效查询既占队列，又可能干扰真实请求。
立即学习“前端免费学习笔记（深入）”；
- ✅ 值得加：
//cdn.example.com（图片/JS/CSS 真实加载）、//api.example.com（首屏后立即fetch）、//hm.baidu.com（统计 SDK 初始化必发） - ❌ 不该加：
//your-site.com（同源，浏览器已缓存或自动优化）、//ad.doubleclick.net（广告联盟不稳定、常被拦截）、//admin.example.com（子域共享主域 DNS 缓存） - ⚠️ 不支持通配符：
//*.example.com无效；也不必为cdn1、cdn2分别加，除非它们由不同权威 DNS 管理
和 preconnect 混用同一域名时，后者直接覆盖前者
dns-prefetch 只做 DNS 解析；preconnect 会进一步完成 TCP 握手 + TLS 协商，开销更大但收益更高。两者目标重叠，不能叠加。
- ✅ 同一域名只选一个：
preconnect更适合确定高频使用、支持 HTTPS 的关键域名（如字体、首屏 API） - ✅
dns-prefetch更适合“确定会访问但不紧急”的场景（如用户点击后加载的第三方评论组件） - ❌ 同时写两者：
preconnect生效，dns-prefetch被忽略，纯属冗余 - ⚠️ 若目标只支持 HTTP 或兼容性要求高（如需支持 IE11），
dns-prefetch是更稳妥的选择
真正难的不是加不加，而是判断“这个域名接下来 1 秒内会不会被请求”“它是否已在其他机制中被覆盖”“它的 DNS 是否本就缓存在系统里”。这些细节没对齐，<link rel="dns-prefetch"> 就只是 HTML 里一行安静的噪音。
