BEM是模块边界声明工具而非标签运动，需定义独立块、语义化元素名、避免嵌套与位置修饰符；其核心价值在于人工约定的模块契约，工具无法替代；须约束选择器权重并禁用随意!important。
为什么直接套用BEM命名会写出一堆冗余class
因为BEM不是“给每个元素加bem__block--modifier”的贴标签运动。真实项目里，header__logo--small和header__logo--large如果只在一处用、逻辑不复用，就等于把样式耦合进HTML结构，反而破坏可维护性。
真正要做的，是把BEM作为**模块边界声明工具**：一个.button块必须能独立存在、有明确定义的变体（.button--primary）、内部元素（.button__icon），且不依赖外部上下文。
- 避免嵌套过深：
.card__content__title__link是错的，应为.card__title-link - 修饰符（
--）只用于同一块的视觉/行为变体，不能表达“位置关系”，比如.menu--in-header就越界了——该拆成.header-menu新块 - 元素名（
__）必须语义化，.button__text可以，.button__div不行
CSS-in-JS或PostCSS插件能否替代BEM的工程价值
不能。BEM解决的不是“怎么写CSS”，而是“怎么定义模块契约”。CSS-in-JS（如Emotion）能生成唯一class，但无法阻止开发者在JS里随意组合样式逻辑；PostCSS插件（如postcss-bem）能自动补全命名，但填不完语义漏洞。
比如你用postcss-bem生成了.modal__overlay--fade，但没定义--fade是否支持duration、timing-function等可配置项，这个修饰符就只是个静态开关，没法被其他模块安全复用。
立即学习“前端免费学习笔记（深入）”；
- BEM的模块契约必须靠人工约定+Code Review保障，工具只是辅助
- 若团队连
.btn和.button都混用，再强的PostCSS也救不了 - CSS-in-JS里仍需遵循BEM思维：Emotion的
styled.button应对应.button块，而非直接写styled.div然后塞一堆内联样式
如何让BEM类名不污染HTML又保持可读性
关键在编译层做映射，而不是手写长串class。用classnames或预处理器函数封装生成逻辑，HTML里只暴露意图，不暴露实现。
// React + classnames 示例
import cn from 'classnames';
const Button = ({ variant, size, children }) => (
<button className={cn('button', {
'button--primary': variant === 'primary',
'button--lg': size === 'lg'
})}>
{children}
</button>
);
- 禁止在JSX里拼接字符串：
className={`button button--${variant}`}容易漏空格、无类型检查 - Sass中用
@function bem()统一生成，而非重复写&__icon，方便后期批量调整命名规则 - 开发时保留原始BEM名（利于调试），构建时可选启用
cssnano的reduceIdents压缩class名（需配套source map）
为什么BEM库上线后反而出现样式冲突和覆盖失效
大概率是忽略了CSS层叠的物理事实：BEM只管命名，不管权重。一个.card__body p选择器比.text--sm权重高，哪怕后者是BEM命名，也会被前者干掉。
工程化封装必须同步约束选择器复杂度。BEM规范本身要求“只用单class选择器”，但没人拦得住开发者手痒写.sidebar .user-card__avatar。
- 用Stylelint配置
selector-max-universal、selector-max-compound-selectors，强制单class引用 - 所有工具类（
.text-center、.mt-2）必须用!important或更高优先级（如[class*="mt-"]）保证不被覆盖 - 组件库发布时，CSS应提取为独立
<link>，避免和业务CSS共用<style>标签导致层叠顺序失控
最麻烦的点往往不在命名，而在没人盯着!important的使用节奏——它能让一个BEM库从可预测变成不可控。
