合并CSS文件能提升加载性能，因其减少关键路径上的网络往返次数，缓解浏览器并发请求限制导致的排队阻塞；但需区分场景：基础通用样式应合并，路由专属或条件样式应按需加载。
为什么合并 CSS 文件能提升加载性能
浏览器对同一域名的并发请求数有限制（通常 6 个），每个 <link rel="stylesheet"> 都算一个独立请求。CSS 文件过多会触发排队、阻塞渲染，尤其在弱网下更明显。合并不是为“减少文件数”而做，而是为降低关键路径上的网络往返次数。
- 首屏关键 CSS 应内联或极小体积合并，避免阻塞 HTML 解析
- 非关键 CSS（如打印样式、主题切换、后台管理页专用）可延迟加载或按需引入
- 注意：HTTP/2 虽支持多路复用，但合并仍有助于减少 TLS 握手、服务器磁盘 I/O 和缓存粒度问题
哪些 CSS 文件适合合并，哪些不该动
盲目合并所有 CSS 可能导致缓存失效率上升、首屏体积膨胀。要区分场景：
-
应该合并：基础重置（
reset.css）、通用工具类（utils.css）、全局组件样式（button.css,card.css）——这些在多数页面都会用到 -
不应合并：单页应用中某路由专属样式（
/admin/dashboard.css）、A/B 测试分支样式、用户主题（dark-theme.css）——它们只在特定条件生效，合并后浪费带宽 -
可拆分+按需注入：媒体查询较多的响应式样式，可提取为
print.css或prefers-reduced-motion.css，用media属性懒加载
构建时合并 CSS 的实操方式（以主流工具为例）
不推荐手动拼接，容易出错且无法处理 @import、路径重写、Source Map 等问题。应交由构建工具处理：
- Webpack：用
MiniCssExtractPlugin+optimization.splitChunks控制提取逻辑，把node_modules中的 CSS 单独打包为vendor.css，业务 CSS 合并为app.css - Vite：默认已做 CSS 合并，可通过
build.rollupOptions.output.manualChunks自定义分组，例如将ant-design相关样式单独抽离 - PostCSS：配合
postcss-import支持@import内联，再用cssnano压缩，适合轻量项目或 CI 构建阶段
/* vite.config.ts 示例：按包名分 chunk */
export default defineConfig({
build: {
rollupOptions: {
output: {
manualChunks: {
antd: ['antd', '@ant-design/icons'],
chart: ['echarts'],
}
}
}
}
})合并后要注意的兼容性与维护陷阱
合并本身简单，但后续维护容易翻车：
立即学习“前端免费学习笔记（深入）”；
- CSS 优先级冲突：多个文件里同名选择器（如
.btn）合并后顺序决定最终样式，必须保证源文件引入顺序稳定，建议用构建工具控制依赖图而非靠@import顺序 - 相对路径失效：原
background: url(./img/icon.png)在合并后可能因输出目录变化而 404，Webpack/Vite 默认会重写，但自定义构建链需确认url()处理逻辑 - Source Map 错位：合并后报错行号指向合并前文件，务必开启
sourceMap: true并验证 devtools 中是否可跳转原始文件 - 缓存穿透风险：一个按钮样式改了，整个
app.css缓存失效。可考虑加内容哈希（app.[contenthash].css），但需配套更新 HTML 中的引用
实际项目中，真正难的不是“怎么合并”，而是判断“哪些该合、哪些该留、合完谁来负责回滚和调试”。别让优化变成新问题的起点。
