dns-prefetch 标签仅从 href 提取主机名做 dns 查询，写错格式（如含路径、缺//、协议不匹配）会静默失效；必须置于 和 后、首个外部资源前；仅加速后续异步跨域请求，不加速首屏同步资源；勿与 preconnect 混用同一域名。
dns-prefetch 标签写错 href 就完全不生效
浏览器只从 href 属性中提取主机名做 DNS 查询，其余内容全被忽略，且不报任何错误——这意味着写错格式等于没写，你查控制台也看不到提示。
-
href="//cdn.example.com/js/app.js"：含路径，整个<link rel="dns-prefetch">标签被静默丢弃 -
href="cdn.example.com"：缺//，被当成本地相对路径，实际查的是https://your-site.com/cdn.example.com -
href="https://cdn.example.com"：显式协议，在 HTTPS 页面中可能被 Safari 跳过；HTTP 页面里又可能因目标只支持 HTTPS 导致后续请求失败
✅ 唯一安全写法只有两种：<link rel="dns-prefetch" href="//cdn.example.com">（推荐，适配当前页协议），或 <link rel="dns-prefetch" href="https://fonts.googleapis.com">（HTTPS 页面更稳）。
放错位置等于白加
浏览器是流式解析 HTML 的，<link rel="dns-prefetch"> 一旦被读到就立即排队执行 DNS 查询。如果它出现在首个 <link rel="stylesheet"> 或 <script src></script> 之后，首屏资源请求大概率已经发出，预解析根本来不及生效。
- ✅ 正确位置：
<meta charset>和<title></title>之后、首个外部资源标签之前 - ❌ 无效位置：塞在
里、包裹在<template></template>中、用 JS 动态创建后document.head.appendChild() - ⚠️ 即使位置正确，若顶部堆了大量阻塞渲染的 CSS/JS，DNS 查询也可能被调度延迟——Safari 尤其保守，常等到空闲或用户交互后才执行
只对后续异步跨域请求有效，首屏资源不加速
dns-prefetch 不加速 <img src>、<script src></script> 这类 HTML 中已声明的同步资源，只影响 JS 中动态发起的 fetch()、懒加载图片、字体 CSS 加载后的 @font-face 请求等。
- ✅ 值得加的域名：
//cdn.example.com（真实加载了 JS/CSS/图片）、//api.example.com（首屏后立即fetch）、//hm.baidu.com（统计 SDK 初始化必发） - ❌ 不该加的域名：
//your-site.com（同源，DNS 缓存已共享）、//admin.example.com（子域共享主域缓存）、//ad.doubleclick.net（不稳定、常被拦截） - ⚠️ 浏览器并发 DNS 查询数通常限 6～10 个，加太多或加错对象，反而挤占真实请求的调度队列
别和 preconnect 混用同一域名
preconnect 已隐含 dns-prefetch 的功能，且会进一步建连 + TLS 握手。两者混用同一域名时，preconnect 会直接覆盖 dns-prefetch，造成冗余甚至浪费连接资源。
- ✅ 场景选择：
dns-prefetch适合开销低、需并发多的域名（如多个 CDN 子域）；preconnect更适合关键且确定高频使用的单个第三方域名（如 API 或字体服务） - ⚠️ 如果目标域名只支持 HTTPS，但当前页是 HTTP，
//fonts.example.com会降级为 HTTP 导致失败——这种场景应改用<link rel="preconnect" href="https://fonts.example.com" crossorigin> - ⚠️
//cdn1.example.com和//cdn2.example.com是两次独立查询，但若它们共用同一套权威 DNS，加一个就够了；若分属不同云厂商（如阿里云 + Cloudflare），才需分别加
真正容易被忽略的是：它不保证执行——浏览器空闲时才做，且可能因资源紧张直接跳过。所以别指望它解决首屏阻塞，它只是锦上添花，不是雪中送炭。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
