合并资源不能仅靠HTML中link/script顺序拼接，因浏览器仍发起多个HTTP请求；关键需服务端参与或构建工具打包，否则无法减少请求数。
为什么合并资源不能只靠
直接把多个 CSS 或 JS 文件按顺序写在 HTML 里，浏览器仍会发起多个 HTTP 请求——合并不是靠“写在一起”，而是让一个请求返回多个资源的内容。关键在于服务端是否参与：纯前端静态 HTML 无法真正减少请求数，除非借助构建工具或服务端逻辑提前打包。
- 浏览器对同一域名的并行连接数有限（通常 6 个），但每个
或都算独立请求 - HTTP/2 虽支持多路复用，但请求头开销、TLS 握手、缓存粒度仍受单文件影响
- 开发阶段保留多文件利于调试；上线前必须合并+压缩，否则白搭
用 Webpack/Vite 打包时如何正确启用 CSS/JS 合并
现代构建工具默认已做代码分割，但「合并」需主动关闭分块或显式配置入口。重点不是“能不能合”，而是“合得是否合理”：过度合并会导致首屏加载变慢，因为用户需要的只是部分样式或逻辑。
- Vite 中默认使用
build.rollupOptions.output.manualChunks控制拆包，设为空对象可强制全量合并（不推荐） - Webpack 中禁用
splitChunks即可让所有模块打进一个bundle.js，但应仅用于小型页面 - 真正有效的做法是提取公共依赖：
export default defineConfig({ build: { rollupOptions: { output: { manualChunks: { vendor: ['vue', 'lodash'], ui: ['element-plus'] } } } } })
内联关键 CSS/JS 时要注意哪些渲染阻塞陷阱
把小体积的首屏必需资源直接写进 HTML 的 或 标签里，能消灭一次 HTTP 请求，但容易误伤性能。
- 超过 ~15KB 的内联 CSS 会显著延长 HTML 解析时间，触发浏览器重排
-
内联脚本默认同步执行，会阻塞 DOM 构建；加type="module"或defer属性才安全 - 内联内容无法被 CDN 缓存，每次 HTML 变更都会导致重复传输相同样式/逻辑
- 推荐只内联「首屏可见区域」所需的最小 CSS（如字体、布局、按钮基础样式），其余仍走外链
使用 HTTP/2 Server Push 还值得尝试吗
Server Push 在 HTTP/2 中曾被寄予厚望，但实际已被主流放弃：Chrome 96+、Firefox 90+ 已移除支持，Nginx 也早在 1.13.10 后弃用该功能。
立即学习“前端免费学习笔记（深入）”；
- Push 不可控：服务器无法知道客户端是否已缓存某资源，强行推送反而浪费带宽
- 优先级难协调：Push 资源可能抢占关键 HTML 的传输带宽
- 替代方案更可靠：使用
显式提示浏览器提前获取关键资源 - 如果还在用老旧 Nginx 配置
http2_push，建议立即删掉——它现在只增加配置复杂度，不带来收益
vite.config.ts 里 build.sourcemap 是否开着（它会让生成的 JS 多一个 .map 请求）。细节比技巧更致命。 
