浏览器对每个<link>标签发起独立HTTP请求，合并需构建工具实现而非手动拼接，首屏资源应控制在≤3个请求内，图片优化宜用WebP+lazy。
浏览器看到多个 <link> 就会发多个 HTTP 请求
无论你在 HTML 里把 10 个 <link rel="stylesheet" href="a.css"> 写得多紧凑，浏览器都会为每个 href 发起独立的 HTTP 请求。这不是“写法问题”，而是协议层行为：每个资源 URL 对应一个请求生命周期（DNS、TCP、TLS、HTTP 头、响应体）。所谓“合并”，不是拼 HTML 标签，而是让一个请求返回多个文件的内容。
HTTP/2 下合并仍有价值，但重点变了
HTTP/2 支持多路复用，10 个 5KB 的 JS 并行传输不比 1 个 50KB 慢——前提是连接已建立、TLS 已握手完成。但首次访问时，多个 <link> 仍触发多个 HEAD/GET，加剧队头阻塞风险。所以关键不是“要不要合”，而是：
- 首屏必需的 CSS/JS 控制在 ≤3 个请求内（哪怕 HTTP/2）
- 非关键资源（如统计脚本）用
async或defer，且不要和同步脚本合并 -
<link rel="preload">必须单独保留，合并后语义失效
手写合并 CSS/JS 文件等于白干
直接复制粘贴所有 CSS 进 all.css，再改 HTML 引用，看似合并了，实则漏掉三件事：
- 模块依赖顺序错乱（
import被扁平化后可能执行失败） - 作用域污染（多个文件里的
var全挤进全局，变量名冲突） - Source map 丢失（调试时无法定位原始代码行）
真正安全的合并必须由构建工具完成：Webpack 关闭 splitChunks 或 Vite 配置 manualChunks，否则前端静态 HTML + CDN 托管永远只是多个独立请求。
立即学习“前端免费学习笔记（深入）”；
图片类资源不能靠改 <img src> 合并
把多个图片路径塞进一个 <img src>，浏览器根本不认。可行方案只有两条：
- CSS Sprites：适合固定尺寸、不常更新的图标集，用
background-position切区域 - Base64 内联：仅适用于压缩后 ≤4KB 的小图标，嵌入 CSS 或 HTML；体积增大约 33%，但免一次 HTTP 往返
更实用的是 WebP + loading="lazy" 组合：现代浏览器都支持 WebP，体积比 PNG 小 30% 以上；非首屏图片根本不会触发请求。
真正影响请求数的，从来不是 HTML 写法，而是服务端是否参与打包或构建工具是否介入。没有这两者，所有“合并”都只是幻觉。
