域名分片在HTTP/1.1下可提升并发，但需满足DNS解析、通配符证书、Cookie隔离和3～5个子域四条件；HTTP/2下反降低性能，因多路复用被破坏且增加TLS开销。
域名分片在 HTTP/1.1 下确实能提升并发请求数，但效果取决于是否满足 DNS、证书、Cookie 和数量控制四个硬性条件；在 HTTP/2 环境下它不仅无效，反而会拖慢加载速度。
为什么 static1.example.com 和 static2.example.com 在 HTTP/1.1 下能提升并发
浏览器对同源（协议+域名+端口）的 TCP 连接数有硬限制，Chrome/Firefox 通常为 6 个。如果所有资源都走 https://static.example.com，第 7 个请求就得排队。换成 https://static1.example.com 和 https://static2.example.com 后，浏览器视其为两个不同源，各自拥有 6 个连接槽位——理论并发上限翻倍。
- DNS 必须能解析全部子域，且指向同一 IP 或 CDN 节点（否则连接分散、失效）
- TLS 证书需覆盖所有子域，推荐通配符证书
*.example.com；否则 Safari/iOS 会拒绝连接 - 子域不能继承主域 Cookie（如
Domain=example.com），否则每个请求都带冗余头，增大传输开销 - 分片数量建议控制在 3～5 个；超过 6 个可能触发 Chrome 总 socket 数上限（约 256），得不偿失
HTTP/2 下用子域名散列反而降低加载效率
HTTP/2 的多路复用（multiplexing）让单个 TCP 连接可并发处理几十个流（stream）。此时再把资源打散到多个子域，等于主动放弃复用优势：
- 每个子域需独立 TLS 握手 + SETTINGS 协商，增加 RTT 延迟
- 连接无法跨子域复用，
main.js和logo.png可能落在不同 TCP 连接上，优先级调度失效 - 若 CDN 配置不一致或 SNI 不匹配，连接可能被强制中断重连
- 实测显示：单域名 + HTTP/2 通常比 4 子域名 + HTTP/1.1 快 15–30%
验证方式很简单：打开 Chrome DevTools → Network 标签页 → 查看 Protocol 列是否全为 h2；再点开任意请求 → Headers → 检查 Connection ID 是否一致。
立即学习“前端免费学习笔记（深入）”；
如何判断当前该不该用子域名散列
别凭经验猜，直接看协议和部署现状：
- 先确认服务端是否启用 HTTP/2：
curl -I https://yourdomain.com查响应头是否有HTTP/2，或用chrome://net-internals/#http2 - 如果 Protocol 是
h2或h3，立刻停用子域名散列，把所有静态资源统一回主域名路径，如https://example.com/assets/ - 如果仍是
http/1.1，且无法升级协议（如老旧内网系统），再考虑分片，并严格按前述 DNS/证书/Cookie/数量四条执行 - 注意：CDN 配置可能掩盖真实协议——有些 CDN 默认关闭 HTTP/2，需在控制台手动开启
替代方案比强行分片更值得投入
与其花精力维护多个子域，不如优先落地更可持续的优化：
- 用
<link rel="preload" href="/main.css" as="style">提前抢占复用连接，避免 HTML 解析空窗期 - 对非首屏 JS 加
async或defer，防止同步脚本阻塞后续资源发现 - 启用
Cache-Control: public, max-age=31536000和 ETag，让重复请求走协商缓存，降低真实并发压力 - 图片资源用
srcset+sizes做响应式加载，避免高清图在弱网下强行并发下载
真正影响并发效果的，从来不是域名写法本身，而是协议层能力是否被释放、资源调度是否被阻塞、以及网络质量是否被感知。子域名散列只是特定历史阶段的权宜之计，现在还依赖它，相当于给电动车装马车轮子——能转，但跑不远。
