BEM本身不增大CSS体积，反而能压低30%以上冗余选择器；其强制扁平命名（如search-form__submit--primary）消除深度嵌套，使样式复用率提升、浏览器匹配更快，Spotify实测体积下降18%。
它不是“好不好用”的问题，而是“用对了没”的问题。BEM本身不解决所有CSS难题，但能锁死三件事：样式归属（谁的）、角色（是什么）、状态（现在什么样）。用错就退化成带下划线的普通类名，用对才显价值。
为什么BEM类名看起来啰嗦却反而减少CSS体积
BEM强制扁平命名（如search-form__submit--primary），直接堵住深度嵌套选择器的生成路径。传统写法.search-form .submit.primary每换一个容器就得复制整条路径；BEM下所有实例共用同一规则，CSS声明只写一次。Spotify实测落地后CSS体积下降18%，主因就是消除了“长得不同、样式相同”的重复选择器。
- 浏览器匹配快，不是因为名字短，而是因为没空格：
search-form__submit走哈希表单次查找；.search-form .submit要逐层回溯父元素 - 构建后可用
grep -r "\.[a-z]\+ \.[a-z]" dist/快速揪出残留的空格选择器 - Sass中写
&__submit { }是安全的，但& .search-form__icon { }会编译出带空格的选择器，破坏BEM性能优势
哪些错误会让BEM彻底失效
团队落地时最容易破功的三个点，只要漏守一个，BEM就退化成“带下划线的普通CSS”：
-
伪BEM：HTML写
class="card card--featured"，但CSS里只定义了.card--featured，漏掉基础块样式，删掉修饰符整个组件就崩 -
跨Block的Element：把
card__title塞进非card容器，或写成card__header__title（BEM不允许Element嵌套Element） -
修饰符滥用：比如
button--width-200px这类写法，把具体值塞进类名，换单位或加媒体查询就得新增一堆类，违背“修饰符描述状态”的原则
JS模板里动态拼接BEM类名的坑
React/Vue中手拼className={`card ${isFeatured ? 'card--featured' : ''}`看似简单，实则高危：
立即学习“前端免费学习笔记（深入）”；
- 大小写混用（
Card__titlevscard__title）在Windows开发机不报错，Linux构建时直接失败 - 漏掉Block前缀、连字符写成
card_element-active，VS Code插件无法识别，补全和校验全部失效 - 用
clsx或封装BEM工厂函数（如bem('card', { featured: isFeatured })）才能稳住底线 - 禁止在模板里直接写
card__title--large这种“Element Modifier”，Modifier只应作用于Block或Element本身，不叠加在子级上
最常被忽略的是：BEM不管CSS加载顺序和层叠权重。如果card__title--small和card__title冲突，不是命名错了，而是引入顺序或!important没管住——BEM只管名字，不管谁覆盖谁。
