CSS文件体积大会延长CSSOM构建时间，阻塞首屏渲染；压缩时应关闭mergeLonghand以防覆盖显式样式，HTTP/2下宜按功能拆分CSS以提升缓存效率，PostCSS插件顺序须为postcss-import→autoprefixer→cssnano。
为什么 CSS 文件体积大反而影响首屏渲染
浏览器解析 HTML 遇到 会阻塞渲染，直到 CSSOM 构建完成。体积越大，下载 + 解析时间越长，白屏时间越明显。尤其在弱网或移动端，100KB 的未压缩 CSS 可能比 30KB 压缩后版本多卡 400ms 以上。
用 cssnano 压缩时必须关掉 mergeLonghand
该选项默认开启，会把 margin-top: 10px; margin-right: 5px; 合并为 margin: 10px 5px 0 0;，看似省字节，但容易覆盖开发者显式设置的其他方向值（比如后续用 margin-bottom: 20px 却被前面的简写重置）。实际项目中更安全的做法是：
- 显式关闭：
mergeLonghand: false - 保留
discardComments: true和reduceTransforms: true - 慎用
normalizeWhitespace，它可能破坏white-space: pre元素的换行效果
合并 CSS 文件前先确认是否真能减少请求数
HTTP/2 下多路复用让多个小 CSS 并发传输效率提升，盲目合并反而牺牲缓存粒度。例如将「通用组件样式」和「页面专属样式」硬塞进一个文件，会导致用户每次访问新页面都得重新下载整块 CSS。判断依据是：
- 静态资源部署了 CDN 且支持强缓存（
Cache-Control: public, max-age=31536000）→ 适合按功能拆分 - 项目仍跑在 HTTP/1.1 环境 → 合并入口级 CSS（如
app.css、vendor.css）仍有效 - 使用了
@import动态引入 → 必须转成构建时合并，否则触发串行请求
PostCSS 插件链顺序影响压缩结果
postcss-import 必须在 cssnano 之前，否则 @import 语句不会被展开，压缩器只看到原始 import 行，无法优化其内容。典型错误配置：
立即学习“前端免费学习笔记（深入）”；
plugins: [ cssnano(), postcssImport() ]
正确顺序应为：
plugins: [
postcssImport(),
autoprefixer(),
cssnano({ preset: 'default' })
]
另外，autoprefixer 要放在 cssnano 前——否则某些旧语法（如 display: flex）可能被误删，因为压缩器识别不了带前缀的规则是否冗余。
真正难处理的是 CSS-in-JS 或动态 class 名场景，这类样式几乎无法通过传统构建压缩生效，得靠运行时去重或服务端 CSS 提取策略来应对。
