为了加速第三方资源 在 head 里一口气写了 CDN 字体 统计 客服四个 preconnect 结果首屏 TTFB 反而多了 300 毫秒 移动端更明显。乍看像缓存或者权限的锅，追下去往往不是。
<link rel='preconnect' href='https://cdn.a.com' crossorigin> <link rel='dns-prefetch' href='https://t.a.com'>
追下去是这么回事：每个 preconnect 都要提前做 DNS 加 TCP 加 TLS 握手 同时开太多会把连接池和带宽分掉 真正关键的域名反而抢不到资源 移动端网络差的时候更吃亏。
「preconnect 使用」这个问题文档写得含糊，实际行为以当前版本为准，别照旧版本的结论套。验证用真实数据走一遍，测试数据太干净，边界情况根本碰不到。
能分两步做的操作就别合成一步，中间看一眼返回值，出问题好判断。报错里带路径的，先去看那个路径在不在、权限对不对。
具体做法是，只给首屏必需而且跨域的域名留 preconnect 一般一到两个就够；按实际使用先后排序 把最关键的那个域名放在最前面；不确定会不会用到的域名换成 dns-prefetch 成本要低很多 也更稳。
验收就看一点，Network 里只剩一两个早期连接 首屏 LCP 比改动前更早 没有连接排队等待。