postcss 不能直接扁平化嵌套选择器；它仅字符串处理，需插件（如 postcss-nested）转译，但不合并冗余选择器，体积与性能问题须靠命名规范（如bem）、压缩工具（cssnano）及设计重构解决。
PostCSS 能不能直接“扁平化”嵌套选择器？
不能。PostCSS 本身不解析语义，它只按规则处理 CSS 字符串；像 postcss-nested 这类插件只是把嵌套语法转成标准 CSS，并不会主动合并或删减生成的选择器——嵌套越深，输出的选择器越长、重复越多，体积自然膨胀。
常见错误现象：.a .b .c .d .e { color: red; } 这种五层嵌套在 Sass 编译后原样保留，而浏览器渲染时每个选择器都要单独匹配，不仅体积大，还拖慢 CSSOM 构建。
- 真正起作用的是后续的压缩/优化阶段，不是预处理阶段
- 如果你依赖
@apply或mixins生成大量重复结构，问题会更隐蔽 - 某些 PostCSS 插件（如
postcss-uncss）能删未用规则，但对“冗余嵌套”无感——它只认最终是否被 DOM 引用
Sass/Less 中怎么避免嵌套爆炸？
核心原则：嵌套是为语义服务，不是为缩进爽快。Sass 的 & 和 Less 的 & 看似方便，但滥用会导致选择器指数级增长。
使用场景举例：写组件内部状态时，容易写出 .card { &__header { &--active { ... } } }，最终产出 .card__header--active 是好的，但若写成 .card { .header { .active { ... } } }，就生成了三重后代选择器，体积和性能双输。
- 优先用 BEM 命名 + 单层类名，而非深度嵌套
- Sass 中慎用
@at-root (without: rule)拆嵌套，它只是移出层级，不解决选择器冗余 - Less 的
.mixin() { &.mod { ... } }比& .mod { ... }更可控，前者生成并集，后者生成后代
有没有工具能自动识别并简化冗余嵌套？
没有通用、可靠的全自动方案。CSS 选择器的语义依赖上下文（HTML 结构、JS 动态类切换），静态分析极易误伤。
但可以靠组合策略收敛体积：
-
cssnano开启mergeLonghand和reduceTransforms，对声明层压缩有效，但对选择器结构无影响 -
postcss-sorting+ 手动约定规则（比如强制同类选择器合并），需团队配合，不能替代设计意识 - 真正有效的“简化”，往往发生在重构阶段：把
.list .item .content span拆成.list-item-content类，再配postcss-bem-linter约束命名
注意：purgecss 只删未用 CSS，如果 HTML 里真有五层嵌套结构且被用到，它就绝不会删——这时候体积问题得回溯到模板或组件设计。
为什么压缩后体积还是下不去？
因为很多“大体积”根本不在 CSS 文件里，而在 source map、注释、未启用的媒体查询、或重复引入的第三方样式中。
典型陷阱：
- Webpack 的
mini-css-extract-plugin默认不 tree-shake CSS，import整个 Bootstrap 就等于打包整个 CSS - Sass 的
@import "bootstrap"和@use "bootstrap"行为不同：@use支持部分加载，但必须配合with显式传参，否则照样全量 - 开发环境开启
sourceMap: true会让最终 CSS 附带 base64 编码的原始文件，体积翻倍不止
查体积构成最直接的方式是用 webpack-bundle-analyzer 看 CSS 来源，而不是盯着压缩率数字猜。
@include 很快，改一个组件的 DOM 层级和样式职责划分，才难。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
