dns-prefetch 的 href 必须为纯域名或协议相对路径，含路径或协议头将导致标签静默失效；须置于 head 靠前位置（meta charset 和 title 后、首 CSS/JS 前）；仅对后续异步跨域请求有效，不可与 preconnect 混用同一域名。
href 必须是纯域名，带路径或协议头就失效
浏览器只从 href 中提取主机名做 DNS 查询，其余内容全被丢弃，且不报错——写错等于没写，极难排查。
-
//cdn.example.com✅ 协议相对写法，最稳妥，适配当前页协议 -
https://fonts.googleapis.com✅ HTTPS 页面可用，但需确保页面本身也是 HTTPS -
https://cdn.example.com/js/app.js❌ 含路径，整个<link rel="dns-prefetch">标签被静默忽略 -
cdn.example.com❌ 缺协议标识，被当成本地路径处理，查的是your-site.com/cdn.example.com -
http://api.example.com❌ HTTPS 页面下大概率跳过，部分浏览器直接丢弃
必须放在 <head> 靠前位置，晚于首个 CSS/JS 就基本无效
浏览器流式解析 HTML，<link rel="dns-prefetch"> 一旦被读到就立即排队执行 DNS 查询。放得太晚，相关资源请求早就发出去了。
- ✅ 推荐位置：
<meta charset>和<title>之后、首个<link rel="stylesheet">或<script>之前 - ❌ 无效位置：塞在
<body>里、包裹在<template>中、用 JS 动态创建并插入（如document.createElement('link')） - ⚠️ 即使位置正确，若前面堆了大量阻塞渲染的 CSS/JS，DNS 查询可能被调度延迟；Safari 更保守，常等到空闲才执行
只对后续异步跨域请求有效，同源或未真实使用的域名纯属浪费
dns-prefetch 不加速首屏资源，只影响 JS 中 fetch()、懒加载图片、字体 CSS 加载等后续异步请求。每个预解析都占用浏览器 DNS 并发队列（通常限 6～10 个）。
- ✅ 值得加：
//cdn.example.com（图片/JS/CSS 真实加载）、//api.example.com（首屏后立即发起 AJAX）、//hm.baidu.com（统计 SDK 初始化必调） - ❌ 不该加：
//your-site.com（同源，浏览器已缓存解析）、//admin.example.com（子域共享主域 DNS 缓存）、//ad.doubleclick.net（不稳定、常被拦截） - ⚠️ 不支持通配符：
//*.example.com无效；也不必为cdn1、cdn2分别加，除非它们由不同权威 DNS 管理
别和 preconnect 混用同一域名，后者已隐含 DNS 解析
preconnect 会完成 DNS + TCP + TLS 全流程，开销更大但收益更高；dns-prefetch 只做 DNS 查询，轻量无连接占用。两者混用同一域名，dns-prefetch 会被忽略，纯属冗余。
立即学习“前端免费学习笔记（深入）”；
- ✅ 关键资源（如首屏必加载的 CDN、API 域名）优先用
<link rel="preconnect" href="https://cdn.example.com" crossorigin> - ✅ 次要但确定会用的第三方域名（如统计、分享）用
dns-prefetch更稳妥 - ❌ 同一域名同时写
dns-prefetch和preconnect—— 浪费标签、干扰 DNS 查询队列调度 - ⚠️ 如果目标域名只支持 HTTPS，而当前页是 HTTP，
//写法会降级为 HTTP 请求失败；此时应换用preconnect并显式声明crossorigin
