生产环境必须用预编译+压缩后的CSS文件，因开发时style-loader内联CSS会增大JS体积、延迟执行、丧失并行下载与Brotli压缩优势；预编译仅转换语法，压缩（如cssnano）才删冗余、降解析开销，二者须严格分步执行，且必须配合contenthash确保缓存更新。
生产环境必须用预编译+压缩后的 CSS 文件，否则首屏渲染会明显变慢，且无法稳定复现线上样式问题。
为什么开发环境的 CSS 不能直接上生产
开发时用 style-loader 把 CSS 内联进 JS bundle，浏览器拿到 JS 后动态插入 <style> 标签。这在本地没问题，但上线后带来两个硬伤：
- JS bundle 体积被撑大，延迟 JS 执行，间接拖慢 CSSOM 构建
- 无法利用浏览器对
<link rel="stylesheet">的并行下载和预加载能力 - 服务端无法对独立 CSS 文件启用 Brotli 压缩（多数 CDN 和 Nginx 默认只对 .css 后缀开启）
压缩前后的真实加载耗时差异
以一个 120KB 的未压缩 CSS 为例（含注释、空格、长命名）：
- 原始文件经 Gzip 后约 28KB，Brotli 后约 23KB
- 压缩后（如用
cssnano）体积降至 65KB，Gzip 后约 16KB，Brotli 后仅 13KB - 关键不是“省了 10KB”，而是：更小的文件让 TTFB 后的下载阶段缩短 40%+，尤其在 3G 或弱网下感知明显
- 更少的字符也意味着浏览器 CSS 解析器要处理的 token 数量下降，FCP 平均快 80–120ms
预编译（如 Sass/Less）和压缩必须分两步做
很多人误以为 “用了 Sass 就等于准备好了生产 CSS”，其实不然：
立即学习“前端免费学习笔记（深入）”；
- 预编译只解决语法转换（
@mixin展开、变量替换），不删空格、不合并重复规则、不简化颜色值 - 压缩工具（如
clean-css、cssnano）才负责移除冗余、重组媒体查询、内联@import—— 这些操作必须在预编译完成之后进行 - 若顺序颠倒（先压缩再预编译），会导致
@import "base.scss"被当作文本直接删掉，编译失败 - Webpack 中典型顺序是：
sass-loader→postcss-loader（含cssnano）→mini-css-extract-plugin
容易被忽略的缓存与哈希陷阱
即使你做了压缩，如果没配对内容哈希，用户可能长期卡在旧版本：
- 只靠
filename: "style.css"+Cache-Control: max-age=31536000，改一行样式也不会触发更新 - 必须用
filename: "style.[contenthash:8].css"，确保内容变则 URL 变 - HTML 中不能硬编码
<link href="style.css">，得靠html-webpack-plugin注入带 hash 的路径 - 若项目用 CSS-in-JS（如 Emotion），JS bundle 的 hash 也得和 CSS 文件 hash 对齐，否则 class 名匹配不上
真正卡住团队的，往往不是“要不要压缩”，而是压缩后没配好哈希、没关掉开发环境的 HMR 干扰、或者把 @import 留在最终 CSS 里导致串行加载——这些点不处理，性能优化就只是纸面数字。
