dns-prefetch仅解析dns，开销小、兼容好，适用于确定会访问但暂不加载的第三方域名；preconnect则完成dns、tcp及tls握手，代价高但收益直接，适用于即将高频加载的关键第三方资源。
两者都用来优化资源加载，但作用阶段和适用场景不同。
rel="dns-prefetch"：适合提前解析第三方域名
它只做 DNS 查询，不建立 TCP 连接，开销小、兼容性好（连 IE11 都支持）。适合那些你确定会访问、但暂时不会加载资源的第三方域名，比如 CDN 域名、统计脚本域名、广告或社交分享接口域名。
- 用在
中，例如：<link rel="dns-prefetch" href="https://cdn.example.com"> - 特别适合跨域请求多、DNS 解析慢的地区（如某些运营商网络）
- 如果域名后续根本不会用到，纯属浪费；如果用了但没配 HTTPS，可能触发不安全警告（现代浏览器通常忽略）
rel="preconnect"：适合即将高频使用的关键第三方服务
它不仅查 DNS，还会完成 TCP 握手和 TLS 协商（如果是 HTTPS），代价更高，但收益也更直接。适合页面中明确要加载资源、且对首屏性能影响大的第三方源，比如字体托管服务（fonts.googleapis.com）、核心 API 域名、主 CDN。
- 同样写在
，例如：<link rel="preconnect" href="https://fonts.googleapis.com"> - 建议配合
crossorigin属性使用（尤其涉及 CORS 资源时），避免预连接被浏览器忽略 - 不要滥用——每个 preconnect 都占用一个 HTTP/1.1 连接槽位，HTTP/2 下影响小些，但仍建议控制在 3–6 个以内
怎么选？看下一步动作
如果只是“将来可能会请求”，优先用 dns-prefetch；如果“接下来 1 秒内就要 fetch 字体、JS 或图片”，就该用 preconnect。实际项目中常组合使用：先 dns-prefetch 备着，再对最关键的 1–2 个源 preconnect。
不复杂但容易忽略。
