BEM能直接压低CSS体积，因其消除嵌套选择器冗余、复用单一类名、提升浏览器匹配效率，并配合PurgeCSS精准删除未使用规则；滥用修饰符或@extend反而增肥。
为什么BEM能直接压低CSS体积
BEM不是“写得更整齐”，而是让选择器失去嵌套冲动，从而从源头掐断冗余规则的生成。传统写法里.card .content p这种后代选择器，每复制一个结构相似的卡片组件，就得重写一遍整条路径；BEM改成card__content-paragraph后，所有地方复用同一个类名，CSS规则只写一次。浏览器匹配也快：单类名查哈希表，嵌套选择器要逐层回溯父元素。
常见错误现象：.header-nav a和.footer-nav ahover样式完全一样，结果编译出两套几乎相同的规则；中后台系统里大量列表项、表单控件、卡片布局，结构相似但DOM路径不同，最容易触发这类膨胀。
- Spotify工程团队实测，BEM后CSS文件体积平均下降18%，主因就是消除了“看起来不同、实际样式雷同”的选择器重复
- block边界必须明确——比如
search-bar是block，search-bar__input不能跨出它的根元素范围 - 别强行BEM的地方：纯静态页、单页营销页、CSS-in-JS主导的项目（此时BEM语义可转为JS变量名）
修饰符（--modifier）怎么用才不反向增肥
--开头的修饰符类名本身不增加体积，但滥用会导致规则爆炸。比如为每个尺寸、颜色、状态都单独写一个类：button--size-small、button--size-medium、button--color-blue……最后CSS里全是碎片化声明。
真正该用修饰符的场景：按钮主题（button--primary）、卡片状态（card--disabled）、表单验证态（input--error）等有限组合，而非像素级控制。
立即学习“前端免费学习笔记（深入）”；
-
button--disabled必须和button同时存在，不能单独用——否则构建工具无法识别其上下文，tree-shaking就失效 - 禁止
button--primary-margin-left-20这类“一义多职”类名，PurgeCSS无法推断使用场景，只能保守保留 - 修饰符只表达语义变体，不混入布局逻辑；颜色、尺寸等应通过CSS自定义属性在block层级统一定义
PurgeCSS为何必须配合BEM才能精准删
BEM不是自动清理工具，它是给PurgeCSS喂的「结构化饲料」。只有类名严格遵循block__elem--mod格式，PurgeCSS才能区分哪些是真实组件类、哪些是临时工具类或遗留类。
常见失效原因：动态拼接类名（如class="card__item--${status}"）、第三方组件类名未显式声明（如直接用<van-button>但没写class="van-button"）、BEM不规范（写了.card-item而非.card__item）。
-
content路径必须覆盖所有class来源：Vue项目要含./src/**/*.vue和./public/index.html；React需加./src/**/*.tsx - 动态类名要用
safelist兜底，例如{ pattern: /--(active|disabled|expanded)/ } - 第三方库类名（如
react-datepicker__day--selected）必须显式加入whitelistPatterns，否则误删
@extend在BEM项目里为什么是体积陷阱
别用@extend优化BEM——它会让体积撑得更大，还埋下维护雷。@extend本质是静态选择器合并，而BEM要求每个类名语义独立、可预测。
当你在.card__title { @extend %text-emphasis; }里用@extend，Sass会把所有匹配%text-emphasis的规则“复制”进.card__title，同时还要为.list__item { @extend %text-emphasis; }再复制一遍——哪怕样式声明完全相同，也会生成两条独立规则。
- 占位符内部不能含任何上下文（如
&:hover、@media、.parent &），否则编译后规则数指数增长 - 真正轻量的做法：用
@mixin封装可复用样式，各组件显式调用，保持类名独立、压缩友好 - 一旦引入
@extend，就等于主动放弃PurgeCSS和tree-shaking的识别能力——体积问题会从构建阶段，转移到运行时
