rel="preconnect"仅在HTTPS域名、href仅含协议+域名、crossorigin属性存在且写法正确三条件全满足时才生效；必须置于<head>顶部<meta charset>后、首个<link rel="stylesheet">或<script>前；href不可带路径或参数；crossorigin必须为空属性值；仅对1秒内必发请求的跨域HTTPS域名有效。
rel="preconnect" 能提早建立通道，但只在三个条件全满足时才真正生效：HTTPS 域名、href 仅含协议+域名、crossorigin 属性存在且写法正确。漏一个，浏览器就当没看见。
preconnect 必须写在 最顶部才起作用
浏览器是流式解析 HTML 的，rel="preconnect" 必须出现在 <meta charset> 后、第一个 <link rel="stylesheet"> 或 <script> 之前。晚一行，连接可能根本不会发起。
- ✅ 正确位置：
<head><link rel="preconnect" href="https://api.example.com" crossorigin></head> - ❌ 放在
<body>里、用 JS 动态插入、或在<link rel="preload">后面，全部无效 - ⚠️ 同一域名多次声明，浏览器只执行第一次，其余直接丢弃
href 必须是完整 HTTPS 协议 + 域名，不能带路径或参数
href 不是资源 URL，而是“连接目标”。它只负责建连，不加载任何内容。带路径或查询参数会导致整个 <link> 被忽略，Network 面板里查不到预连记录。
- ✅ 正确：
https://fonts.gstatic.com、https://cdn.example.com - ❌ 错误：
http://fonts.googleapis.com（Chrome 直接忽略 HTTP）、//cdn.example.com（协议相对写法降级为dns-prefetch）、https://cdn.example.com/js/app.js（含路径，整条失效） - ⚠️ 同源地址如
https://your-site.com加了也无效，浏览器自动复用已有连接
crossorigin 属性不是可选，是复用连接的开关
浏览器把带和不带 crossorigin 的连接视为两个隔离池。后续请求若需要 CORS（比如 fetch()、字体、带凭据的 API），就必须匹配预连时的凭据模式，否则白建。
立即学习“前端免费学习笔记（深入）”；
- ✅ 正确写法：
<link rel="preconnect" href="https://api.example.com" crossorigin>（空属性值，等价于crossorigin="anonymous"） - ❌ 错误写法：
crossorigin=""（非法 HTML，被忽略）、crossorigin="anonymous"（带等号，部分解析器报错） - ⚠️ 如果
fetch()显式传了credentials: 'include'，服务端必须返回Access-Control-Allow-Credentials: true，此时仍要保留crossorigin，但需确认服务端 CORS 配置能匹配
只对 1 秒内必发请求的第三方 HTTPS 域名有效
preconnect 不是“越早建越好”，而是“建完马上要用”。连接建好后若 1 秒内没发起真实请求，浏览器可能回收它；若服务端没返回正确的 CORS 响应头，连接也无法复用。
- ✅ 典型有效场景：
https://fonts.googleapis.com（CSS 请求紧随其后）、首屏fetch("https://api.example.com")、CDN 上未缓存的首屏 JS/CSS - ❌ 无效场景：
https://analytics.example.com（用户点击后才上报）、备用 CDN（如backup.cdn.example.com）、HTTP 域名、重定向跳转后的最终域名（如 preconnectapi.v1.example.com，但它 301 到api.v2.example.com） - ⚠️ Chrome 并发上限约 6 个，再多的
rel="preconnect"会被排队甚至丢弃，还可能挤占主域连接资源
最容易被忽略的是：preconnect 是否真被复用了，不取决于 Network 面板有没有“preconnect”记录，而取决于你后续请求的协议、凭据模式、域名粒度是否和预连声明完全一致——差一个字符、少一个属性，连接就进不了复用池。
