浏览器并发连接限制导致同域名请求阶梯式排队：HTTP/1.1下同一域名默认最多6个并发连接，超出请求在Stalled状态等待，Stalled时长随序号递增且紧接Initial connection，表明受浏览器策略限制而非服务端或网络问题。

直接看瀑布图里同域名请求的排队模式——如果多个请求在 Stalled 或 Queueing 阶段明显错开、呈“阶梯式”延迟启动，大概率是被浏览器并发连接数限制卡住了。

确认是否真受域名并发限制

同一域名下 HTTP/1.1 请求默认最多 6 个同时建立连接。超出的请求会挂起在 Stalled（或 Queueing）状态，直到前面某个连接释放。这不是服务端问题，而是浏览器自身策略。

• 筛选同域名资源：在 Network 过滤框输入 domain:example.com（替换为你的真实域名），只保留该域下的请求
• 按 Waterfall 列从长到短排序，观察前 6 个请求是否基本同步开始；第 7 个及之后的请求是否在前一批完成前就已处于 Stalled 状态，且 Stalled 时间接近前一个请求的 Content Download 结束时刻
• 对比不同子域：比如 static.example.com 和 cdn.example.com 的请求是否各自形成独立的 6 连接组——若它们没被合并为同一源，则不受彼此影响

识别典型 Stalled 模式

Stalled 时间长 ≠ 一定是并发限制，但结合上下文可快速判断：

• 多个 JS/CSS/图片请求在相同域名下，Stalled 时间集中在 100–300ms 区间，且随序号递增（如第7个 stall 120ms，第8个 stall 240ms……），这是典型排队信号
• Stalled 后紧跟橙色 Initial connection（TCP 连接），说明它没卡在 DNS 或 TLS，而是等连接空闲——排除网络层问题
• 若所有 Stalled 都极短（

验证与绕过方式

不靠猜，用实测确认并给出可行解：

• 启用 HTTP/2 或 HTTP/3：在支持的服务器上开启后，同域名可复用单个连接，Stalled 基本消失——检查协议列（Protocol）是否显示 h2 或 h3
• 域名分片（Domain Sharding）：把静态资源分散到 sub1.example.com、sub2.example.com 等不同子域，每个子域独立享有 6 连接额度（注意：HTTP/2 下反而可能降低性能，慎用）
• 改用 resource hint：对关键资源加 <link rel="preload" href="..." as="script">，让浏览器提前建连，缓解阻塞
• 检查是否误用同步脚本：一个 <script src="a.js"></script> 未设 async/defer，会阻塞后续同域请求解析和发起——这比并发限制更隐蔽，但效果类似

辅助判断技巧

单看瀑布图不够，需联动其他信息交叉验证：

• 右键表头勾选 Connection ID 列：相同 Connection ID 的请求属于同一个 TCP 连接；若多个请求共用 ID 且时间连续，说明复用成功；若 ID 频繁变化且数量远超请求数，说明连接未复用
• 看 Initiator：Stalled 的请求若 Initiator 是 script，说明是 JS 动态创建的，可能本可延迟或合并；若是 parser，则是 HTML 解析时自然触发，更符合并发限制场景
• 对比禁用缓存前后：Disable cache 开启后，Stalled 模式更清晰；若关闭缓存后 Stalled 显著变长，说明原来部分请求走了内存缓存，掩盖了瓶颈