现代浏览器限制同域名并发数为6–8个，是兼顾TCP开销、服务器负载与历史兼容性的权衡设计；CSS易卡在此处因默认阻塞渲染且每个请求需完整网络流程，HTTP/2仅缓解而非根治，关键在合并、预加载、媒体查询隔离与按需注入。
现代浏览器对 <link rel="stylesheet"> 的并发加载数有限制，不是 bug，而是有意为之的权衡设计——它既防客户端资源耗尽，也避免服务器被压垮。
为什么限制在 6–8 个同域名连接？
这个数字源于 TCP 连接管理与历史兼容性的平衡：
- 操作系统端口和线程切换有开销，无限制并发会拖慢浏览器自身调度
- HTTP/1.1 的
Keep-Alive机制依赖复用连接，频繁建连比复用更慢 - 服务器通常设了并发阈值（如 Nginx 的
worker_connections），大量并发请求可能触发限流或直接拒绝 - 老浏览器（如 IE6/7）只允许 2 个，现代浏览器放宽到 6–8 是向后兼容+性能折中
为什么 CSS 特别容易卡在这里？
<link> 默认阻塞渲染，且每个都算一个独立 HTTP 请求：
- 哪怕只有 1KB 的
base.css和theme.css，也会各自排队走 DNS → TCP → TLS → HTTP 流程 - HTTP/1.1 下，10 个
<link>很可能串行加载，尤其当 CDN 未开启 HTTP/2 或域名未做发散 -
@import更糟：它在 CSS 解析阶段才触发新请求，不仅不并行，还延迟 CSSOM 构建
HTTP/2 真的解决这个问题了吗？
没完全解决，只是缓解：
立即学习“前端免费学习笔记（深入）”；
- HTTP/2 支持多路复用，理论上一个连接可并发传输多个资源，但实际仍受浏览器连接池调度影响
- 如果所有 CSS 都走同一域名，即使 HTTP/2，
<link>的解析顺序、优先级、缓存失效策略仍可能导致“逻辑串行” - CDN 对
contenthash文件名识别不准时，合并后的 CSS 更新不生效，反而让旧缓存拖慢首屏
真正卡点不在协议层，而在“如何让关键 CSS 尽快可用”——合并、预加载、媒体查询隔离、路由级按需注入，这些动作比单纯盯着并发数更有实际收益。
