浏览器对同一域名的并发连接数限制（如Chrome的6个HTTP/1.1连接）会导致资源排队、解析中断和渲染阻塞，表现为pending请求在Waterfall中错开出现；可通过分域加载、preload/prefetch、动态导入等手段绕过，而非仅依赖defer/async。
浏览器对同一域名的并发连接数有限制，HTML 解析本身不卡，但资源请求排队会导致后续 <script>、<link rel="stylesheet"> 实际加载延迟，进而触发解析中断或渲染阻塞——这不是“慢”，而是“等”。
Chrome 对同一域名最多 6 个 HTTP/1.1 连接
这是最常被忽略的底层约束。当 HTML 中密集写入 10 个 <script src="a.js">、<link href="b.css">，且都指向同一域名（如 cdn.example.com）时，第 7 个资源会进入 pending 状态，直到前面某一个完成下载或连接释放。
- HTTP/2 虽支持多路复用，但部分旧版 iOS Safari 在 TLS 握手阶段仍受连接数影响，小文件过多反而更慢
-
<link rel="preload">不计入并发限制，但只预加载不执行，不能替代<script>或<link rel="stylesheet"> - 本地开发用
file://协议时，该限制失效，但其他限制（如无压缩、无缓存）会掩盖真实问题
如何识别是否真被并发限制卡住
打开 DevTools → Network 面板 → 刷新页面 → 按 “Waterfall” 排序 → 找出所有状态为 pending 的请求，看它们是否集中在同一域名下、起始时间是否明显错开（比如间隔 200ms+）。
- 若多个
.js或.css请求在 “Queueing” 阶段停留 >100ms，基本可判定是连接争抢 - 注意区分：TTFB 高是服务端问题；“Stalled” 时间长才是客户端连接瓶颈
- 右键某个 pending 请求 → “Block request domain”，屏蔽该域名后刷新，观察其他资源是否提前启动——这是最直接验证法
绕过并发限制的实操手段
不靠“合并所有 JS/CSS”这种粗暴方式，而是分层控制资源调度节奏。
立即学习“前端免费学习笔记（深入）”；
- 关键资源走主域名（如
app.example.com），非关键资源拆到子域名（static.example.com、fonts.example.com），每个子域独立计数 - 第三方资源（如
analytics.js）必须用async+ 动态fetch()注入，避免初始 HTML 里硬编码，否则一上来就占满连接 - 对字体、图标等低优先级资源，用
<link rel="prefetch">而非preload，它不抢占带宽，只在空闲时预取 - 构建时启用 HTTP/2 Server Push（仅限 HTTP/2 环境），服务端主动推送关键 CSS/JS，绕过客户端请求队列
defer 和 async 无法解决并发排队问题
defer 只让脚本不阻塞 HTML 解析，async 只让脚本下载不阻塞解析——但两者都改变不了资源请求发起时刻。如果 5 个 async 脚本同时指向同一域名，照样排队。
- 真正有效的是控制“何时发请求”，不是“何时执行”
- 首屏必需脚本保留
defer，其余用requestIdleCallback(() => { import('./non-critical.js') })延迟到主线程空闲时才加载 - 避免在
<head>里堆砌一堆<link rel="stylesheet">，改用 JS 动态加载 +media="print"切换方案，把请求分散到 DOMContentLoaded 后
并发限制看不见摸不着，但它真实存在，且只在真实网络环境（非 localhost）中暴露。很多人优化了半天 JS 执行逻辑，却忘了看 Network 面板里那一排灰色的 pending 条——那才是真正的瓶颈入口。
