能，但仅当首屏JS初始化即fetch且服务端返回Access-Control-Allow-Origin时生效；须写在<head>最顶部、带正确crossorigin属性，否则无效甚至拖慢加载。
preconnect 对跨域 API 域名是否真能削减延迟？
能，但只在「首屏 JS 初始化就发起 fetch」且服务端返回了 Access-Control-Allow-Origin 时生效。如果 API 请求是用户点击后才触发、或首屏根本没调用，加了 preconnect 不仅没收益，还会占用浏览器并发连接名额（通常限 6 个），拖慢真实资源加载。
跨域 API 的 preconnect 必须带 crossorigin 吗？
必须。浏览器把带 crossorigin 和不带的连接视为两个独立连接池。即使你只是 fetch('https://api.example.com/health') 这种简单 GET，只要服务端返回了 CORS 头，后续请求就必须复用带凭据标识的预连接——漏写 crossorigin，预连白建，浏览器仍要重走 DNS + TCP + TLS。
-
crossorigin或crossorigin="anonymous"都合法；crossorigin=""是非法 HTML，会被忽略 - 若 API 响应头含
Access-Control-Allow-Credentials: true，则必须用crossorigin="use-credentials"，且前端 fetch 要配credentials: 'include' - 纯 public API（如
Access-Control-Allow-Origin: *）用crossorigin即可
preconnect 放错位置会导致 API 请求反而变慢
它必须写在 <head> 最顶部，早于所有 <link rel="stylesheet"> 和 <script>。浏览器流式解析，晚几行就可能错过空闲连接窗口——尤其当首屏 CSS 或 JS 文件较大时，HTML 解析被阻塞，preconnect 指令迟迟不被执行，等真正 fetch 时连接还没建好，延迟反而比不加还高。
- 别把它塞在
<meta>后面、或跟在 Google Fonts 的preconnect后面凑数 - 不要用 JS 动态插入：
document.head.appendChild(...)完全无效，浏览器不认 - href 只能是协议 + 域名，如
https://api.example.com✅，不能带路径或参数：https://api.example.com/v1❌
怎么验证 preconnect 对 API 是否起效？
打开 Chrome DevTools → Network 面板，筛选 Other 类型，找 preconnect 条目，点开看时间线：若 domainlookup、connectStart、secureConnectionStart 三项耗时明显低于后续同域名的 fetch 请求，说明成功复用。
立即学习“前端免费学习笔记（深入）”；
- 若看到
preconnect条目但后续 API 请求仍从零开始建连，大概率是crossorigin漏写或写错 - 若
preconnect显示Failed或直接不出现，检查 href 是否拼错、是否用了 HTTP 协议（Chrome 忽略http://） - Lighthouse 的 “Preconnect to required origins” 审计项只报建议，不保证实际复用，必须手动验时间线
真正容易被忽略的是：preconnect 不是“加了就快”，而是“加对了才快”。它对连接时机极其敏感，对 CORS 配置极其诚实——写错一个属性，或放错一行位置，效果就归零。
