preconnect明明写了，为什么DNS预解析还是没生效？

preconnect 没生效不一定是写法问题，你那个标准写法 <link rel="preconnect" href="https://cdn.example.com"> 其实没问题。但有几个关键点容易被忽略，导致你以为它没起作用。

首先是缓存干扰。你说资源走了浏览器缓存，那 DNS 查询确实不会重新触发，自然看不到预解析的效果。preconnect 是为“未来可能的连接”做准备，如果资源已经缓存命中，浏览器压根不需要发起新请求，当然也不会展示 DNS 时间。

其次，preconnect 只建立连接通道（TCP + TLS），不保证一定使用。你得确保后续有真实请求发往这个域名。比如页面中真的引用了 cdn.example.com 下的 js、css 或图片，且这些请求没有被缓存拦截。

验证是否生效的正确方式是：硬刷新页面（Ctrl+Shift+R）清除缓存干扰，在网络面板里找那个 CDN 域名的首个请求，看 Timing 里的 “Connection Start” 是否早于请求开始时间。如果有提前量，说明 preconnect 成功建立了连接。

还有一点，某些 CDN 在同一 IP 集群下，浏览器可能会复用已有连接，看起来像没走预解析。可以试试用 Chrome 的 chrome://net-internals/#dns 查看 DNS 缓存，或者用 performance.getEntries() 拿到具体资源的 performance timing 数据分析。

最后，服务器不用特别配置，但确保响应头不要带 X-Frame-Options 或 CSP 限制太死，否则可能阻断预连接。建议加上 crossorigin 属性，尤其是跨域资源：<link rel="preconnect" href="https://cdn.example.com" crossorigin>，避免凭据问题导致连接中断。

总之别看“DNS: 0ms”下结论，重点看连接建立时机和实际性能数据。

这个问题很典型，我也踩过同样的坑。先说结论：preconnect 写了但看不到 DNS 预解析效果，大概率不是你写错了，而是 Chrome 开发者工具的显示机制和实际行为不一致，再加上缓存干扰，让你误以为没生效。

我们一步步来拆解：

第一步，确认你的用法是对的。你写的 <link rel="preconnect" href="https://cdn.example.com"> 语法完全正确。如果这个域名需要跨域请求资源（比如字体、JS、CSS），最好加上 crossorigin 属性，哪怕它允许匿名请求。所以更稳妥的写法是：

<link rel="preconnect" href="https://cdn.example.com" crossorigin>

这里需要注意，加 crossorigin 不是为了让 preconnect 成功，而是告诉浏览器“我接下来要跟这个域名做跨域请求”，浏览器才会真正建立连接。如果不加，某些情况下 preconnect 会被忽略。

第二步，为什么网络面板里 DNS 查询显示“0 ms”？因为 Chrome 的开发者工具在展示“水球图”时，对预解析的 DNS 时间处理得很模糊。如果你已经访问过这个域名，或者系统/浏览器缓存了 DNS，那它就不会重新查，自然显示 0ms。这不是 preconnect 没生效，而是你根本不需要再查了。

更糟的是，Chrome 有时候不会把 preconnect 触发的 DNS 查询单独列出来。它可能已经提前完成了 DNS 解析、TCP 握手甚至 TLS 协商，但你在后续资源加载时看到的记录却是“直接开始连接”，这就是预期行为——preconnect 的目的就是让这些步骤提前发生，等真请求来的时候可以直接用已建立的连接。

第三步，怎么验证 preconnect 真的生效了？别看单个资源的水球图，要看“Connection ID”是否复用。操作如下：

打开开发者工具 → Network 面板 → 找到一个从 cdn.example.com 加载的资源 → 点开详情 → 查看 Timing 标签页 → 注意“Queueing”阶段的提示。

如果看到类似“Finished early because socket was previously warmed up”的提示，恭喜，preconnect 生效了。这说明连接已经被提前建立，请求不用排队等 DNS 和 TCP。

另一个办法是清空所有缓存后测试。按 Ctrl+Shift+Delete 清除浏览数据，勾选“缓存的图片和文件”，然后在隐身窗口打开页面，刷新一次。这时候你可能会看到某个资源的 DNS 查询时间不再是 0ms，而且整个加载时间变短了。对比关闭 preconnect 后的表现，差异会更明显。

第四步，服务器配置有没有影响？一般来说没有。preconnect 是客户端行为，只要你的 link 标签能被浏览器解析，就会尝试发起预连接。但要注意几个边界情况：

- 域名必须是 HTTPS，否则 preconnect 会被忽略（出于安全考虑）
- 如果 CDN 使用了 HTTP/2 或 HTTP/3，连接复用更强，preconnect 的收益会降低，但依然有帮助
- 浏览器对 preconnect 有并发限制，一般最多同时处理 6 个，多余的会被排队或丢弃

第五步，实际优化建议：

1. 把 preconnect 放在 head 里越早越好，最好在第一个 script 或 css 之前
2. 只对关键第三方域名使用，比如 CDN、字体、API 接口。别乱加，每个 preconnect 都有性能成本
3. 如果你知道只用 HTTP 而不需要 TCP 连接，可以用 dns-prefetch 代替：

<link rel="dns-prefetch" href="//cdn.example.com">

它的开销比 preconnect 小，只做 DNS 预解析，适合那些不一定马上用但可能访问的域名。

最后提醒一点：不要过度依赖开发者工具的视觉反馈。浏览器内部做了太多优化，而 DevTools 只展示了冰山一角。判断性能优化是否有效，应该结合 Lighthouse 报告、Web Vitals 数据和真实用户监控来看。

你现在可以试着去掉 preconnect，跑一次 Lighthouse，再加回来跑一次，看“Reduce DNS lookups”或“Efficiently encode images”这类建议有没有变化。这才是靠谱的验证方式。