href必须仅含协议和域名，路径或端口会导致标签静默失效；需置于head最前，只预解析确定会用的跨域域名，且不与preconnect混用同一域名。
href 必须只含协议+域名，路径和端口会让标签静默失效
浏览器对 href 的解析非常严格：它只提取主机名做 DNS 查询，其余部分全被丢弃。写错格式不会报错，但等于没写——你刷新页面、打开 DevTools，也看不到任何提示。
- ✅ 正确：
<link rel="dns-prefetch" href="//cdn.example.com">（双斜杠协议相对，兼容性好） - ✅ 正确：
<link rel="dns-prefetch" href="https://fonts.googleapis.com">（HTTPS 页面更稳，避免混合内容） - ❌ 错误：
<link rel="dns-prefetch" href="//cdn.example.com/js/app.js">（含路径，整个标签被忽略） - ❌ 错误：
<link rel="dns-prefetch" href="cdn.example.com:8080">（无协议+显式端口，被当成本地相对路径） - ❌ 错误：
<link rel="dns-prefetch" href="http://api.example.com">（HTTP 协议在 HTTPS 页面中大概率被跳过）
注意：//fonts.gstatic.com 和 //fonts.googleapis.com 是两个独立域名，不能互相替代；也不支持通配符，//*.example.com 无效。
必须放在 <head> 最前面，晚于首个外部资源就基本白加
浏览器是流式解析 HTML 的，<link rel="dns-prefetch"> 一旦被读到就立即排队执行。如果它出现在首个 <link rel="stylesheet"> 或 <script> 之后，相关资源请求往往已经发出，预解析根本来不及生效。
- ✅ 推荐位置顺序：
<meta charset>→<title>→<link rel="dns-prefetch">× N → 首个外部资源标签 - ❌ 无效位置：塞在
<body>里、包裹在<template>中、或用 JS 动态创建插入（如document.createElement('link')） - ⚠️ 它不阻塞渲染，但若放在大量 CSS/JS 后面，DNS 查询可能被首屏关键资源抢占调度优先级
- ⚠️ Safari 更保守，常延迟到空闲或用户交互后才执行，放太晚等于放弃
只加确定会用的第三方跨域域名，同源和子域不用加
每个 dns-prefetch 都是一次真实 DNS 查询，浏览器并发上限通常为 6～10 个。无效查询不仅浪费系统资源，还可能挤占真实请求的调度优先级。
立即学习“前端免费学习笔记（深入）”；
- ✅ 值得加：
//cdn.example.com（图片/JS/CSS 真实加载）、//api.example.com（首屏后立即fetch）、//hm.baidu.com（统计 SDK 初始化必发） - ❌ 不该加：
//your-site.com（同源，DNS 缓存已共享）、//admin.example.com（子域共享主域缓存）、//ad.doubleclick.net（广告联盟不稳定、常被拦截） - ⚠️ 别为
cdn1.example.com和cdn2.example.com分别加，除非它们由不同权威 DNS 管理；也不必凑数加备用 CDN 或懒加载模块所用域名
别和 preconnect 混用同一域名，后者会覆盖前者
dns-prefetch 只做 DNS 解析，开销极低；preconnect 会进一步建 TCP 连接 + TLS 握手，资源占用高且受并发限制（通常最多 6 个）。两者目标不同，混用不仅冗余，还可能浪费连接资源。
- ✅ 同一域名只选一个：
preconnect更激进，适合确定高频且支持 HTTPS 的域名（如<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>） - ✅
dns-prefetch更轻量，适合“有可能”用到、或不确定是否真加载的场景（如埋点上报域名//stats.example.com） - ❌ 同一域名既写了
preconnect又写了dns-prefetch→ 后者被忽略，纯属冗余
最易被忽略的点是：它不加速当前页面的首屏资源加载，只对后续异步请求（如 JS 中的 fetch、图片懒加载、点击弹窗引入第三方组件）真正用到的跨域域名有效。加错位置、写错格式、滥用域名，反而拖慢关键请求。
