bem是大型项目守住样式边界的底线方案：单类名如.user-card__avatar--loading支持一次哈希查找，而.user-card .avatar需从右往左逐层回溯父节点，dom越深性能差距越显著；空格即隐患，块前缀实现自解释与隔离，伪bem和跨block命名则导致失控。
因为BEM不是“看起来规范”，而是当项目进入百人协作、多端同构、微前端并存阶段时，唯一能靠命名本身守住样式边界的底线方案。
为什么单类名选择器（如.user-card__avatar--loading）比嵌套选择器快
BEM 类名强制单类名触发，浏览器对 .user-card__avatar--loading 是一次哈希查找；而 .user-card .avatar 需从右往左逐层向上回溯父节点，DOM 层级越深，性能差距越明显。现代浏览器虽优化了选择器引擎，但 DevTools → Computed → Styles 面板里只要看到空格，就说明存在潜在回溯开销。
- 构建后可用
grep -r "\.[a-z]\+ \.[a-z]" dist/快速扫出所有带空格的选择器 - Sass 中写
.user-card { &__avatar { } }安全；但.user-card { & .user-card__badge { } }会编译出带空格的后代选择器，破坏 BEM 隔离性 - 空格不是“写法问题”，是作用域失控的早期信号——它意味着样式依赖 DOM 结构，而结构在 SSR 或微前端中极易被其他模块意外修改
为什么开源和中大型项目特别依赖类名自解释性
没人会为你写文档说明 .card__title 属于哪个组件、能不能单独复用。BEM 的块前缀就是所有权声明：product-card__title 搜索就能定位整个组件边界，包括模板、样式、JS 逻辑；而 .title 或 .card-title 在千组件项目里等于裸奔。
- GitHub 搜索
grep -r "checkout-form__" .能瞬间锁定结账表单全部文件 - 第三方开发者 fork 后改样式，不会误动
search-form__submit-btn——块名天然隔离 - PHP/Java 模板直出 HTML 时，
modal__close--hovered比tw-6 tw-h-6更易审计、可追溯、CDN 可缓存
为什么修饰符滥用和伪BEM是项目失控的起点
真正让 BEM 失效的，从来不是没写对 __ 或 --，而是规则松动后产生的隐性耦合：
-
伪BEM：HTML 写
class="card card--featured"，但 CSS 只定义了.card--featured，删掉修饰符整个组件就崩 -
跨Block 元素：写
card__header__title，违反 BEM 层级规则，IDE 跳转失效，工具链无法校验 -
修饰符含具体值：如
button--width-200px，换单位就得新增button--width-20rem，响应式或主题切换时必然卡死 - 正确做法是布尔组合：
button--primary button--large button--disabled，每个修饰符独立生效、可被单独覆盖
真正难的不是写出 block__element--modifier，而是每次敲下 __ 和 -- 时，都得确认：这个元素是不是它所属 Block 的固有部分？这个修饰符描述的是稳定可枚举的状态，还是临时视觉补丁？这种判断没法自动化，只能靠人盯住。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
