合并静态资源能显著降低TCP和TLS握手次数，避开DNS查询、三次握手（1.5×RTT）、TLS协商（约2×RTT）等高开销环节；主流浏览器同域名并发限制为6个（移动端4个），30个文件合并为3个后，握手次数从30次降至3次，大幅缩短首屏加载时间。
合并静态资源请求能直接减少 TCP 连接和 TLS 协商次数，从而避开网络层最耗时的环节——每次新请求都要经历 DNS 查询、TCP 三次握手（1.5×RTT）、HTTPS 的 TLS 握手（额外约 2×RTT）。这些开销叠加起来，对首屏加载影响极大。
为什么合并能降低连接建立开销
浏览器对同一域名有并发连接数限制（主流桌面浏览器为 6 个，移动端常为 4 个）。当页面需加载 30 个 JS/CSS 文件，而只允许同时建 6 条连接时，其余请求必须排队等待。合并后变成 3 个请求，不仅排队减少，更关键的是：多个小文件可复用同一条已建立的 TCP+TLS 连接（HTTP/1.1 默认 keep-alive），省去重复握手成本。
- DNS 查询只需一次（域名解析缓存后更省）
- TCP 握手从 30 次降为 3 次，节省约 4.5 秒 RTT（按平均 RTT=100ms 计算）
- TLS 协商从 30 次降为 3 次，避免密钥交换、证书验证等高开销步骤反复执行
JS 和 CSS 合并的具体操作方式
不是简单复制粘贴代码，而是借助构建流程确保正确性与可维护性：
- Webpack：在 entry 中将多个入口统一指向一个 chunk，如
entry: { app: ['./src/a.js', './src/b.js', './src/c.js'] }，配合 optimization.splitChunks 关闭自动分包，即可输出单个 bundle - Rollup/Vite：使用 input 数组接收多个源文件，设置 output.format = 'iife' 或 'es'，天然支持合并输出
- CSS 场景：用 PostCSS 插件（如 postcss-import）在主样式中
@import其他文件，再通过构建工具一次性编译压缩，避免运行时多次 fetch
要注意的边界情况
合并不是万能解法，需结合实际权衡：
立即学习“Java免费学习笔记（深入）”；
- 过大的单文件会拖慢首屏渲染——关键 JS 应拆出核心逻辑（如路由、骨架屏），非关键功能延迟加载
- 缓存失效粒度变粗：一个文件里只改了一行，整个 bundle 缓存就失效；可通过内容哈希（
[contenthash]）解决 - HTTP/2 多路复用削弱了合并收益，但 TLS 握手和队头阻塞（尤其在弱网下）仍使合理合并有价值
配套优化建议
合并只是起点，需搭配其他手段放大效果：
- 启用 Gzip/Brotli 压缩：减小合并后文件体积，进一步缩短传输时间
- 开启 HTTP/2 或 HTTP/3：提升多资源并行传输效率，缓解合并可能带来的“大文件阻塞”问题
- 预加载关键资源：
<link rel="preload" href="main.js" as="script">提前触发下载，不阻塞解析 - 服务端开启 keep-alive 和 early hints（103 状态码），让浏览器尽早发起关键资源请求
