子域名散列是突破浏览器同域名并发请求数6～8个限制的最有效手段，通过static1/2.example.com等独立域名各自获得独立连接池，但需确保DNS、CDN、证书、Cookie清除等基础设施正确配置。
浏览器对同一域名的并发请求数限制在6～8个，这是硬性限制，不是优化技巧能绕开的。用子域名散列（如 static1.example.com、static2.example.com）是目前最直接、兼容性最好、见效最快的突破手段。
为什么子域名能提升并发数
浏览器按「协议 + 域名 + 端口」三元组管理连接池，static1.example.com 和 static2.example.com 被视为两个独立域名，各自拥有6～8个连接槽位。这不是“欺骗”，而是标准行为——HTTP/1.1 的连接复用机制本就如此设计。
常见错误现象：资源加载明显卡在第7个请求后，Network 面板里大量请求状态为 pending，且所有 pending 请求都指向同一个域名。
- 必须确保各子域名解析到同一台 CDN 或源站（通过 CNAME 指向同一节点），否则可能引入额外 DNS 查询或跨地域延迟
- 子域名不能带 Cookie：主域
example.com设置的Cookie默认会随static1.example.com请求发出，徒增请求头体积；应在 CDN 或 Nginx 层显式清除Cookie头 - 不要超过5个子域名：Chrome 对总 TCP 连接数也有上限（通常 256），过多子域反而触发连接竞争，实测 3～4 个收益最稳
如何安全配置子域名散列
关键不在“怎么写 HTML”，而在“怎么配基础设施”。很多团队写了 static2.example.com 却没配 DNS 或 CDN，结果 404 比并发提升还明显。
立即学习“前端免费学习笔记（深入）”；
- CNAME 记录必须生效：
static1.example.com→your-cdn-provider.net，不能只改 HTML 就以为完成了 - CDN 缓存策略要统一：不同子域名的缓存 Key 应忽略 Host 头，否则同一张图在
static1和static2下被当成两个资源缓存，浪费空间 - HTTPS 证书需覆盖全部子域名：用通配符证书
*.example.com，别用单域名证书，否则 Safari 会直接拦截 - 本地开发时可用 hosts 文件模拟，但 CI/CD 构建产物中必须用真实子域名，否则上线后失效
和 HTTP/2 多路复用的关系
子域名散列对 HTTP/2 效果有限，甚至可能削弱其优势。HTTP/2 的核心价值是单连接多路复用，而子域名强制创建多个连接，反而绕过了这个优化。
所以真实建议是：优先升级 HTTP/2，再考虑是否需要子域名散列。如果仍需支持旧版 Android WebView（HTTP/2 支持率低）、或大量资源必须走 HTTP/1.1 CDN，则子域名仍是必要补充。
- HTTP/2 开启后，单域名并发瓶颈基本消失，此时子域名主要价值转为「缓存分片」和「CDN 节点负载均衡」
- 若已启用 HTTP/2，又强行加子域名，需确认 CDN 是否开启
http2并且对所有子域名生效（Nginx 配置里listen 443 ssl http2必须写全） - HTTP/2 不支持 Server Push（已被主流浏览器弃用），别再为此保留子域名做推送通道
实际效果与容易忽略的坑
在真实电商首页测试中，从单域名切到 3 个子域名后，首屏图片加载完成时间从 1.8s 降至 1.1s（WiFi 环境），但弱网下收益几乎为零——因为 RTT 高时，并发数压根不是瓶颈，TCP 慢启动和丢包重传才是。
- 别只看 Chrome DevTools 的 Waterfall：它显示的是“请求发起时间”，不是“连接建立时间”。用
chrome://net-internals/#events查HOST_RESOLVER_IMPL_REQUEST和SOCKET_POOL_CONNECT才能看到真实连接排队 - 子域名不解决 DNS 查询延迟：首次访问时，3 个子域名会触发 3 次 DNS 查询，可配合
<link rel="dns-prefetch" href="https://static1.example.com">提前解析 - 移动端 WebView（尤其安卓 5–7）对子域名连接复用更保守，实测并发提升常打 5 折，必须真机验证
子域名散列不是银弹，它只解决一个明确问题：HTTP/1.1 下同域名 TCP 连接不够用。一旦你确认服务端没开 HTTP/2、CDN 不支持、或必须兼容老环境，那就老老实实配 3 个子域名，别试图用 10 个来“堆性能”。
