dns-prefetch标签必须置于最前，即和之后、首个或之前；href仅支持//域名或显式https协议，含路径、协议头或缺协议均无效；仅对后续确有请求的高频跨域域名有效，同源或低频域名反会挤占dns并发队列。
dns-prefetch 标签写在哪才真正起作用
必须放在 最前面，早于所有外部资源声明——不是“随便塞进 head 里就行”，而是紧接在 <meta charset> 和 <title></title> 之后、首个 <link rel="stylesheet"> 或 <script></script> 之前。
浏览器是流式解析 HTML 的，<link rel="dns-prefetch"> 被读到就立即排队；放晚了，首屏 CSS/JS 请求早已发出，DNS 预解析根本来不及生效。
- ✅ 正确顺序：
<meta charset>→<title></title>→<link rel="dns-prefetch" href="//cdn.example.com">→<link rel="stylesheet"> - ❌ 错误做法：丢在
里、包在<template></template>中、用document.createElement('link')动态插入 - ⚠️ 它不阻塞渲染，但依赖空闲时机执行；若首屏资源抢占了全部网络带宽和 CPU，预解析可能被延迟甚至跳过
href 值怎么写才会被浏览器识别
只接受两种合法格式：//cdn.example.com（协议相对）或 https://fonts.googleapis.com（HTTPS 页面中显式 HTTPS），其余写法大概率静默失效。
浏览器仅从 href 中提取主机名，路径、协议头、查询参数全被忽略；写错等于白加，且不会报错、无控制台提示，极难排查。
- ✅ 推荐：
<link rel="dns-prefetch" href="//api.example.com">—— 自动适配当前页协议，兼容性好 - ❌ 无效：
https://api.example.com—— 旧版 Safari 可能跳过 - ❌ 无效：
//api.example.com/v1/login—— 含路径，整个标签被忽略 - ❌ 无效：
cdn.example.com—— 缺少//，被当作相对路径处理
preconnect 和 dns-prefetch 到底该选哪个
不是“功能叠加”，而是成本与确定性的权衡：preconnect 会真实建立 TCP 连接 + TLS 握手，开销高、受并发限制（通常最多 6 个）；dns-prefetch 只做 DNS 查询，轻量但效果有限。
- ✅ 用
preconnect：域名确定高频使用、支持 HTTPS、且已知首屏必发请求（如https://fonts.gstatic.com）；务必加crossorigin属性，否则 Safari 可能忽略 - ✅ 用
dns-prefetch：只是“可能用到”或用户交互后才触发（如埋点上报域名//stats.example.com）、或备用 CDN（//cdn2.example.com） - ❌ 别混用：同一域名同时写两者，
preconnect会覆盖dns-prefetch，后者纯冗余
哪些域名值得加，哪些加了反而拖慢页面
每个 dns-prefetch 都是一次真实 DNS 查询，浏览器并发上限通常为 6～10 个；无效查询不仅浪费资源，还可能挤占关键请求的调度优先级。
- ✅ 值得加：
//cdn.example.com（首屏图片/CSS/JS 真实加载源）、//api.example.com（首屏后立即fetch()）、//fonts.googleapis.com（CSS 中明确@import引入） - ❌ 别加：
//your-site.com（同源，DNS 已缓存）、//admin.example.com（子域共享主域缓存）、//ad.doubleclick.net（不稳定、常被拦截） - ⚠️ 不支持通配符：
//*.example.com无效；//cdn1.example.com和//cdn2.example.com必须分别声明，且需确认两者 DNS 管理独立
最易被忽略的是：它完全静默——没请求，预解析就是空转；没验证，你永远不知道它有没有真跑起来。查 Network 面板的 domainlookup 时间是否下降，才是唯一可靠依据。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
