dns-prefetch 和 preconnect 的 href 格式及位置要求极为严格：dns-prefetch 仅提取主机名，路径、协议缺失或通配符均无效；preconnect 必须带协议且跨域必加 crossorigin；二者均须置于首屏资源前，否则失效。
dns-prefetch 的 href 格式错一点就白写
浏览器对 href 值的解析极其严格，只提取主机名，其余全丢弃。写错不会报错，但标签被静默忽略——你在 Network 面板里根本看不到任何 DNS 查询痕迹，排查起来像在找幽灵。
-
//cdn.example.com✅ 协议相对写法，兼容性最好，推荐首选 -
https://fonts.googleapis.com✅ HTTPS 页面中显式写法更稳，避免字体服务因协议降级失败 -
https://cdn.example.com❌ 旧版 Safari 可能跳过 -
//cdn.example.com/js/app.js❌ 含路径，整个<link rel="dns-prefetch">被忽略 -
cdn.example.com❌ 缺双斜杠，被当成本地相对路径处理 -
//*.example.com❌ 通配符无效，DNS 不支持泛解析预加载
preconnect 必须带协议且跨域必加 crossorigin
preconnect 比 dns-prefetch 激进得多，它会真实触发 DNS + TCP + TLS 全流程，因此格式和上下文约束更强。写错不仅无效，还可能浪费连接池或触发降级。
-
href="https://fonts.gstatic.com"✅ 必须显式协议，//写法不被支持 -
crossorigin属性必须存在，哪怕目标是同源域名——Safari 等浏览器会因此忽略无该属性的preconnect -
<link rel="preconnect" href="https://fonts.googleapis.com" crossorigin>和<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>是两个独立条目，不能合并 - 同一域名同时写
dns-prefetch和preconnect：后者覆盖前者，前者纯冗余
位置放错等于没写，不是塞进 head 就行
浏览器流式解析 HTML，dns-prefetch 和 preconnect 必须在首个外部资源（如 <link rel="stylesheet"> 或 <script src="...">）之前被读到，否则首屏请求早已发出，预操作完全失效。
- ✅ 正确顺序：
<meta charset="utf-8">→<title>→<link rel="dns-prefetch" href="//cdn.example.com">→<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>→ 首个 CSS/JS 标签 - ❌ 塞进
<body>、<template>或用document.createElement('link')动态插入：全部无效 - ⚠️ 放在大量内联 CSS 或 JS 之后：即使语法和位置“合法”，也可能被首屏关键请求抢占调度优先级，尤其在 Safari 中常延迟到空闲时才执行
哪些域名该加，哪些加了反而拖慢页面
每个 dns-prefetch 是一次真实 DNS 查询，每个 preconnect 占用一个 TCP 连接槽位（浏览器通常限制并发 6 个）。盲目堆砌不仅无效，还会挤占真实请求资源。
立即学习“前端免费学习笔记（深入）”；
- ✅ 值得加：
//cdn.example.com（首屏图片/CSS/JS 真实加载）、https://api.example.com（首屏后立即 fetch）、https://hm.baidu.com（统计 SDK 初始化必发） - ❌ 不该加：
//your-site.com（同源，DNS 缓存已共享）、//admin.example.com（子域共享主域缓存）、//ad.doubleclick.net（广告联盟不稳定、常被拦截） - ⚠️ 别为
cdn1.example.com和cdn2.example.com分别加，除非它们由不同权威 DNS 管理；也别凑数加懒加载模块所用域名——等用户交互时再用new Image().src或fetch()触发更合理
