dns-prefetch必须置于和之后、首个外部资源前，仅支持协议+域名格式，无效写法无报错但失效；同一域名勿与preconnect混用，且不保证执行。
dns-prefetch必须放在最前面，否则基本失效
浏览器是流式解析 HTML 的，dns-prefetch 标签一旦被读到就立即排队执行；如果它出现在首个 <link rel="stylesheet"> 或 <script></script> 之后，很可能首屏资源请求已经发出，预解析来不及起作用。
- ✅ 正确位置：
<meta charset>和<title></title>之后、第一个外部资源引用之前 - ❌ 错误做法：塞在
里、包裹在<template></template>中、用document.createElement('link')动态插入 - ⚠️ Safari 更保守，常延迟到空闲或用户交互后才执行；放太晚等于白写，且无任何控制台提示
href只能是协议+域名，带路径或端口会整个标签被忽略
dns-prefetch 只提取 href 中的主机名做 DNS 查询，其余部分全丢弃。写错格式不会报错，但标签完全不生效——这是最隐蔽的坑。
- ✅ 合法写法：
<link rel="dns-prefetch" href="https://fonts.googleapis.com">、<link rel="dns-prefetch" href="//cdn.example.com"> - ❌ 非法写法：
href="https://cdn.example.com/js/app.js"（含路径）、href="cdn.example.com:8080"（显式端口）、href="http:/cdn.example.com"（协议拼错） - ⚠️
//fonts.gstatic.com和//fonts.googleapis.com是两个独立域名，不能互相替代；也不支持通配符，//*.example.com无效
只加确定高频使用的第三方跨域域名，别凑数
每个 dns-prefetch 都是一次真实 DNS 查询，浏览器并发上限通常为 6～10 个。无效查询不仅白耗资源，还可能挤占关键请求的调度优先级。
- ✅ 值得加：
//cdn.example.com（首屏图片/JS/CSS 真实加载）、//api.example.com（首屏后立即fetch）、//hm.baidu.com（统计 SDK 初始化必发） - ❌ 不该加：
//your-site.com（同源，DNS 已缓存）、//ad.doubleclick.net（广告联盟不稳定、常被拦截）、//admin.example.com（子域共享主域 DNS 缓存） - ⚠️ 别为
cdn1.example.com和cdn2.example.com分别加，除非它们由不同权威 DNS 管理；否则纯属冗余
别和preconnect混用同一域名，否则后者覆盖前者
dns-prefetch 只做 DNS 解析，开销极低；preconnect 会进一步建 TCP 连接 + TLS 握手，资源占用高，且受浏览器并发限制（通常最多 6 个）。两者功能重叠，但强度不同。
- ✅ 同一域名只选一个：
preconnect更激进，适合确定高频使用且支持 HTTPS 的域名（如字体服务）；“可能用到”或“用户触发后才发请求”的场景，用dns-prefetch更稳妥 - ❌ 同时写两者：
preconnect会覆盖dns-prefetch，后者被忽略，纯属冗余 - ⚠️ 如果当前页是 HTTPS，但写了
http://，该标签大概率被跳过；//在 HTTP 页面中会降级为 HTTP，可能失败——这种场景应改用preconnect并声明crossorigin
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
