BEM选择器更快是因为单类名（如.user-card__avatar--loading）支持浏览器一次哈希查找，而嵌套选择器（如.user-card .avatar）需从右往左逐层回溯父节点，DOM越深性能差距越显著。
因为BEM不是“过时的命名习惯”，而是解决 CSS 类名语义模糊、作用域失控、协作成本飙升这三类问题的最小可行方案——它不依赖构建工具，不绑定框架，也不靠运行时魔法，只靠命名本身把“谁的、什么、什么状态”三个问题塞进类名里。
为什么 BEM 选择器在现代浏览器里依然比嵌套选择器快
BEM 的性能优势不来自名字长短，而来自单类名选择器一次哈希查找。比如 .user-card__avatar--loading 是浏览器直接查 class 表；而 .user-card .avatar 会让浏览器先找所有 .avatar 元素，再逐层向上检查父级是否匹配 .user-card，DOM 越深越慢。
- DevTools → Elements → Computed → Styles 面板里一眼就能看出有没有空格——有空格就是潜在性能隐患
- Sass 中写
.user-card { &__avatar { } }安全；但写.user-card { & .user-card__badge { } }就会编译出带空格的选择器 - 构建后用
grep -r "\.[a-z]\+ \.[a-z]" dist/快速揪出残留的空格选择器
为什么 React/Vue 组件结构天然适配 BEM 命名
.user-card 对应 UserCard.vue 或 UserCard.jsx，Block 名就是组件名直译，目录、文件、类名三者一致，新人看类名就能反推组件位置。
- 没有
.card .header这类嵌套选择器，父组件 DOM 结构微调（比如加 wrapper）不会导致子组件样式失效 - 第三方库或 SSR 直出 HTML 时，JS 还没执行，
user-card__avatar这种类名就是唯一契约，不靠哈希、不靠 scope 属性 - 微前端场景下，
payment-button__icon--disabled天然带命名空间，不会和宿主项目冲突
BEM 最容易被绕开的三个破功点
规范写得再好，只要这三点没守住，BEM 就退化成“带下划线的普通 CSS”：
立即学习“前端免费学习笔记（深入）”；
-
伪BEM：HTML 写
class="user-card user-card--loading"，但 CSS 只定义了.user-card--loading，漏掉基础块样式，删 modifier 整个组件就崩 -
跨 Block 的 Element：把
user-card__avatar放到非user-card容器里，或写成user-card__header__title（BEM 不允许 Element 嵌套 Element） -
修饰符滥用：写
button--width-200px这类含具体值的类名，换单位或加媒体查询就得新增一堆类，违背“修饰符描述状态”的原则
真正难的不是写对一个类名，而是每次写 __ 和 -- 时都得问自己：这个元素是不是它所属 Block 的固有部分？这个修饰符是不是可枚举、可复用、不带硬编码值的状态？——这种判断没法自动化，只能靠人盯住。
