真正压缩CSS需多层优化：Sass设compressed并禁用sourceMap；PostCSS插件须在编译后、压缩前执行且配置HTML入口和伪类白名单；@use替代@import按需引入；splitChunks提取公共样式；最后用Chrome覆盖率分析验证。
怎么用 Sass 的 --style compressed 真正压小 CSS 文件
压缩不是开个开关就完事。Sass 默认输出是 expanded，设成 compressed 确实能砍掉空格换行，但对选择器重复、冗余规则、未使用的变量毫无作用。
真正起效的前提是：源码本身没大量手写重复块，且没开启 sourceMap（它会往末尾塞 base64 字符串，反而让文件变大）。
- 命令行编译时加
--no-source-map，别信默认值 - Webpack 中用
sass-loader时，additionalData或implementation配置不干扰压缩逻辑，但sassOptions.outputStyle必须显式设为'compressed' - 注意：
compressed模式下@debug和@warn会被静默丢弃，调试阶段别开着它跑构建
PostCSS 插件清理无用 CSS 规则前要确认什么
postcss-discard-unused 或 uncss 类工具常被误用——它们靠分析 HTML 入口找“用到的选择器”，但对动态插入的类名、JS 切换的 .is-active、CSS-in-JS 注入的样式完全失效。
实际项目里，这类工具更适合静态站点或 SSR 渲染后已知 DOM 结构的场景。
立即学习“前端免费学习笔记（深入）”；
- 务必在构建流程中放在 Sass 编译之后、CSS 压缩（如
cssnano）之前执行 - 如果用了
content选项指定 HTML 文件路径，确保它包含所有可能挂载组件的模板（比如 Vue 的.vue单文件组件需额外配置postcss-html解析器） - 遇到
:hover、[data-theme="dark"]这类伪类/属性选择器被误删，得在插件ignore列表里手动加白名单
为什么 @use 替代 @import 能减少体积
@import 是简单拼接，哪怕只用 utils.scss 里的一个 px2rem() 函数，也会把整个文件（含一堆没调用的 mixin 和变量）全塞进输出；@use 则只引入真正被引用的部分，且自动做命名空间隔离，避免意外覆盖。
但迁移有坑：旧版 @import 支持跨文件变量共享（比如在 A.scss 定义 $color，B.scss 直接用），@use 下必须显式 @forward 或从原模块 via 导出。
- 升级前先跑
sass-migrator module --verbose自动改写，别手改 -
@use "vars" as v后，必须写v.$primary，不能直接写$primary - 第三方库（如 Bootstrap 5）若还没切
@use，暂时保留@import，混用时注意加载顺序：先@use自己的模块，再@import第三方
Webpack 构建中 CSS 提取和分割的体积陷阱
mini-css-extract-plugin 把 CSS 单独抽成文件是对的，但它默认按入口 chunk 分割，容易导致多个页面共用的 base.css 被重复打进每个 chunk 里。
解决办法不是关提取，而是用 splitChunks 强制提取公共部分。
- 配置
cacheGroups时，test: /node_modules/只抓第三方，还得加一条匹配/src/assets/styles/的规则，把基础样式单独拎出来 - 别设
minSize: 0—— 太小的 CSS chunk 会导致 HTTP 请求增多，反而拖慢首屏 - 启用
runtimeChunk: 'single'后，记得检查生成的runtime.js是否意外把 CSS 加载逻辑也打包进去了（某些老版本插件会）
体积优化真正的难点不在工具链开关，而在判断哪些代码“确实没用”——浏览器里跑一遍覆盖率分析（chrome://inspect > Coverage），比任何静态扫描都准。但很多人忘了这一步，或者只测了首页，漏掉后台管理页的样式分支。
