bem本身不提速，真正起效的是单类名选择器（如.card__title）避免浏览器从右往左回溯父节点；错误写法如.card .card__title、sass嵌套编译出空格选择器、媒体查询内退化等反而拖慢渲染。
为什么BEM本身不提速，但能让你写出更快的CSS
BEM不是性能开关，它不改变浏览器渲染流程，也不跳过layout阶段。真正起作用的是你最终生成的选择器是否为单类名——.card__title匹配快，.card .card__title匹配慢，差别在于浏览器从右往左回溯父节点的次数。很多团队写了.button--primary却还在HTML里套<div class="button"><span class="button--primary"></span></div>，CSS里再写.button .button--primary，等于用BEM名字包装了嵌套选择器，性能毫无改善。
哪些BEM写法实际拖慢渲染
常见错误不是命名不对，而是编译或手写时悄悄引入了空格、关系符或伪类组合：
- 用Sass嵌套时写
.card { &__content { &:hover { } } }→ 编译出.card .card__content:hover，空格+伪类双重开销 - 媒体查询内退化：
@media (min-width: 768px) { .card .card__title { font-size: 1.2em; } }→ 应该是@media () { .card__title--lg { } - 修饰符混入布局逻辑：
.list__item--full-width里写width: 100%，状态切换直接触发重排 - 误用
:is()包裹：:is(.card) .card__title看似扁平，实则仍是两层匹配，且iOS Safari 15.4以下不支持
如何验证你的BEM真正在生效
别信Sass文件结构，只看最终注入页面的CSS字符串：
- 打开DevTools → Elements → 选中任意带
card__title的元素 → 右侧Styles面板点开对应规则 → 确认选择器是.card__title，不是.card .card__title或div.card__title - 构建后执行：
grep -r "\.[a-z]\+ \.[a-z]" dist/css/，命中即表示存在空格分隔的嵌套选择器 - Webpack项目检查
css-loader是否启用exportOnlyLocals: true，避免局部样式意外泄漏成全局嵌套 - CI中加校验脚本：匹配到
__但没紧贴单词（如.menu__ item）或--前后有空格，一律报错
移动端和列表场景下的关键约束
在DOM量大、CPU弱的环境里，BEM的“扁平”必须落实到每一处：
- VirtualList中每个item根节点只能挂一个Block类：
<li class="user-list__item">，禁止叠加class="user-list__item list-item" - 禁用
:hover直接作用于元素：.card__title:hover语义错误且不可控；应由JS切换.card--hovered，再配.card--hovered .card__title（虽含空格，但仅限状态类，且深度≤2） - 伪类必须前置到Block：
.card--loading .card__spinner比.card__spinner:loading更安全，后者根本不存在 - 所有Modifier不得包含
display、position、float、width等layout属性，只管颜色、圆角、阴影等paint属性
.header__logo--dark这个名字有多长，而是你在某个Sass文件里随手写的.sidebar &__avatar悄悄编译出了.sidebar .user-card__avatar——这种错误不会报错，却让每千个头像加载都多一次父级回溯。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
