域名分片在HTTP/1.1下有效，因其绕过浏览器同源并发连接数限制（6～8个），通过将资源分配至不同子域（如static1.example.com、static2.example.com），使各子域拥有独立连接池，从而提升并行下载能力。
直接结论：在 HTTP/1.1 环境下，合理使用子域名散列（如 static1.example.com、static2.example.com）可将静态资源并发加载数从单域名的 6～8 个提升至 18～40 个；但在 HTTP/2 或 HTTP/3 环境下，它反而降低性能，应禁用。
为什么子域名散列在 HTTP/1.1 下能提升并发数
HTTP/1.1 没有多路复用，每个请求需独占一个 TCP 连接；浏览器对「同源」（协议+域名+端口）强制限制并发连接数为 6～8 个。这意味着： - 所有https://cdn.example.com 下的图片、CSS、JS 共享同一池子，第 7 个请求就得排队
- 改用 https://static1.example.com、https://static2.example.com、https://static3.example.com 后，浏览器视为三个不同源，各自分配 6 连接槽位 → 理论上限达 18 个
但这个提升不是线性叠加的，受制于：
- DNS 解析延迟：每个新子域首次访问都要查 DNS，未预热时反而拖慢首屏
- TLS 握手开销：每个子域需独立完成完整握手（尤其无会话复用时）
- 浏览器总 socket 上限：Chrome 单页约 256 个 socket，分片超 5 个子域后可能触发系统级限流
HTTP/2 环境下启用子域名散列反而有害
HTTP/2 的多路复用机制让单个 TCP 连接可承载数十个并行流（stream），此时： - 子域名散列强制浏览器建立多个 TCP 连接，浪费 TLS 握手、慢启动、SETTINGS 帧协商等开销 - 不同子域间无法共享流优先级、无法统一调度，main.js 和 logo.png 可能被塞进不同连接，失去带宽抢占能力
- 实测显示：单域名 + HTTP/2 比 4 子域名 + HTTP/1.1 平均快 15–30%，尤其在弱网或高 RTT 场景更明显
验证是否已启用 HTTP/2：
- 打开 Chrome DevTools → Network 标签页 → 刷新页面 → 查看任意请求的
Protocol列 - 若显示
h2，说明已启用；若为http/1.1或空，则未就绪，此时分片才有效
实施子域名散列必须满足的硬性条件
不是把域名改个前缀就能生效，以下三点任一缺失，效果归零甚至负向： -DNS 必须能正确解析所有子域名（如 static1.example.com 和 static2.example.com 都指向同一 CDN IP），否则出现 NXDOMAIN 或超时
- TLS 证书必须覆盖全部子域名：推荐通配符证书 *.example.com；若用单域名证书，Safari/iOS 会直接拒绝连接
- Cookie 必须隔离：主站设了 Domain=example.com 的 Cookie，所有子域请求都会自动携带，增大请求头体积；静态资源域名应完全无 Cookie（例如用 cdn.example.com 而非 static.example.com）
如何让 HTML 中的散列真正生效
光改 URL 不够，标签写法决定浏览器能否预加载、复用、调度： - 在<head> 中添加 <link rel="dns-prefetch" href="//static1.example.com"> 和 <link rel="dns-prefetch" href="//static2.example.com">，提前触发 DNS 解析
- 图片、CSS、JS 的 src 或 href 必须显式写死子域名，如 <img src="https://static1.example.com/a.jpg">；不要用 JS 动态拼接后再插入 DOM，否则错过预加载时机
- 禁止跨子域共享 localStorage 或 IndexedDB 名称——它们仍按完整域名隔离，但开发者容易误判为“同源可共用”
- 不要混用：避免部分资源走 static1、部分走 cdn.example.com，这会额外增加连接管理成本
真正起作用的从来不是“用了几个子域”，而是你有没有让浏览器在解析 HTML 的第一毫秒就开始建连、预热、填满连接池。一旦服务端升级到 HTTP/2，这套逻辑就要整个翻过来——这时候最有效的并发优化，是把所有资源收回到一个域名下，并用 <link rel="preload" as="style"> 抢占复用通道。
立即学习“前端免费学习笔记（深入）”；
