CSS无需混淆，只需构建阶段用cssnano安全压缩；必须确保postcss-import在cssnano前以处理@import，避免误删选择器或样式丢失，并绑定contenthash防止缓存旧文件。
cssnano 压缩 vs 误配的“混淆”参数
很多人在 Webpack 或 PostCSS 配置里看到 obfuscate: true 或启用 reduceIdents 就以为开启了 CSS 混淆，其实这是危险操作：reduceIdents 会把 .btn-primary 这类选择器当成无用标识符删掉，导致样式丢失；discardUnused 若未配合正确的 AST 分析（比如没跑过 JS 提取 class），也会误删仍在使用的规则。真正该开的是 mergeLonghand、normalizeWhitespace 这类安全压缩项。
为什么必须在构建阶段压缩，不能 runtime 处理
浏览器加载 CSS 是阻塞渲染的关键路径，<link rel="stylesheet"> 的内容必须同步解析生成 CSSOM。如果靠 JS 在页面加载后再读取、压缩、重写 <style> 标签，不仅破坏渲染流程，还会触发二次样式计算，FCP 延迟 200ms+。构建阶段压缩后，文件体积下降 40%–60%，TTFB 后下载更快，尤其在 3G 网络下效果明显。
压缩顺序错误会导致 @import 失效
PostCSS 插件链中，cssnano 必须放在 postcss-import 之后，否则 @import "base.css" 还没展开就被当成普通注释或无效语句跳过，最终产出的 CSS 缺失依赖。常见错误配置是把 cssnano 写在 postcss-import 前面，或者用在线工具直接压单个文件却忽略它引用了其他 CSS。
Less/Sass 编译和压缩必须分两步
预编译（如 sass-loader）只做语法转换：变量替换、@mixin 展开、嵌套转平级；它不删空格、不合并重复声明、不简化颜色值。压缩（如 css-minimizer-webpack-plugin）才是干这事的。若顺序颠倒——比如先压缩再编译——@import "vars.scss" 会被当成字符串直接删掉，编译直接报错。Webpack 正确链路是：sass-loader → postcss-loader（含 cssnano）→ mini-css-extract-plugin。
立即学习“前端免费学习笔记（深入）”；
真正容易被忽略的不是“要不要压缩”，而是压缩是否覆盖了所有入口、是否绑定了contenthash、以及 HTML 中的 <link href="..."> 是否由 html-webpack-plugin 动态注入——漏掉任意一环，都可能导致用户缓存旧 CSS，改了样式却看不到。 
