BEM通过单类名选择器提升性能并防止样式污染。它用块-元素-修饰符命名强制归属，杜绝嵌套选择器和跨模块冲突，要求响应式逻辑绑定到具体BEM类，且需工具链严格校验。
因为不遵循 BEM，大型项目里改一个 padding 就可能让三个页面的按钮错位、弹窗遮挡失效、响应式断点集体失灵——这不是偶然出错，而是结构失控后的必然连锁反应。
为什么单类名选择器比嵌套选择器快
BEM 的性能优势不是名字短，而是浏览器匹配时少走弯路。.user-card__avatar--loading 是单类名，浏览器直接查哈希表；而 .user-card .avatar 会让浏览器先找所有 .avatar 元素，再逐层往上检查父级是否匹配 .user-card，DOM 越深越慢。
DevTools → Elements → Computed → Styles 面板里一眼就能看出有没有空格——有空格就是潜在性能隐患。构建后用 grep -r "\.[a-z]\+ \.[a-z]" dist/ 可快速揪出残留的空格选择器。
Sass 中写 .user-card { &__avatar { } } 安全；但写 .user-card { & .user-card__badge { } } 就会编译出带空格的选择器，破坏 BEM 隔离性。
立即学习“前端免费学习笔记（深入）”；
为什么 BEM 能防样式“跨模块污染”
没有 BEM 时，.btn 这种类名等于没定义归属：Billing 子应用和 UserManagement 子应用都引入同一份按钮样式，又各自加了 .btn { padding: 4px }，浏览器只认最后加载的那条，没人能说清谁赢谁输。
BEM 把归属直接写进名字：btn__label、checkout-form__submit-btn--disabled——类名本身就成了接口契约，使用者不用翻文档就知道这是谁家的按钮、什么状态、在哪上下文生效。
常见破功点：
- 伪 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 这类含具体值的类名，换单位或加媒体查询就得新增一堆类
为什么响应式逻辑必须绑定到 BEM 类上
常见错误是把 is-mobile 类随手加在按钮、弹窗、表单上，最后变成全局开关；@media 规则分散在 header.css、card.scss、common.css 里，改个断点要 grep -r "min-width" 半小时。
所有响应式变更必须绑定到明确的 BEM 类，比如：
- product-card--stacked（整块结构切换）
- button__icon--right（仅元素自身微调）
- 禁止写 .product-card .price 配合媒体查询——这种选择器一挪 DOM 就失效，且无法被 stylelint-selector-bem-pattern 拦截
@media 块内只允许出现一个 BEM 类选择器，不许嵌套，不许带空格。
真正难的不是写对一个类名
真正难的是每次写 __ 和 -- 时都得问自己：这个元素是不是它所属 Block 的固有部分？
- .card__title--large ❌：modifier 应该挂在 block 上，不是 element 上；正确是 .card--large .card__title
- .user-info__name 和 .user-name 并存，看似相似实则无法复用，后期维护成本翻倍
- BEM 只管名字，不管谁覆盖谁：.card__title--large 和 .card__title--small 冲突，不是命名错，是 CSS 引入顺序或层叠权重没管住
最容易被忽略的是：工具链里没配 stylelint-selector-bem-pattern enforce strict pattern，CI 阶段不拦截，靠人眼 Review 根本拦不住松动。
