BEM的block__element--modifier结构通过命名自带层级意图和状态语义，使类名可自我解释，如header__logo--dark明确表示header块内的logo元素启用dark变体，从而减少协作困惑。
为什么BEM的block__element--modifier结构能减少“这个类名谁写的？干啥用的？”这类问题
因为名字本身携带了层级意图和状态语义，不用翻JS或HTML就能猜出作用范围。比如header__logo--dark明确表示：这是header块里的logo元素，当前启用dark变体。协作时别人改样式不会误动sidebar__logo，也不会把--dark随手加到按钮上——规则锁死了命名空间边界。
常见错误是把__写成_（如header_logo），导致工具链（如PostCSS插件、BEM工具）无法识别结构；或者在modifier里塞具体值，比如button--width-200px，这违反了“修饰符描述状态而非样式”的原则，后续换单位或响应式时就卡住。
- 块名必须是独立、可复用的视觉单元（
card、form-field），不能是red-card这种带样式的命名 - 元素名只描述角色（
__title、__actions），不描述位置（避免__top-title） - 修饰符名用形容词或布尔值（
--disabled、--expanded），不用尺寸/颜色等具体值
如何让团队新人三分钟看懂一个BEM类名的含义
靠强制约定+编辑器提示。VS Code装Auto Rename Tag插件后，改class="card__content"会同步更新对应CSS里的.card__content；再配个stylelint-config-bem，保存时立刻报错：Unexpected BEM element name "card__content-inner" (no-descending-specificity)——说明你嵌套太深，该拆块了。
实际协作中，最常踩的坑是“伪BEM”：HTML里写class="card card--featured"，但CSS里只写了.card--featured，漏了基础块样式。结果删掉--featured类，整个card就崩了。BEM要求所有修饰符必须和基础块共存。
立即学习“前端免费学习笔记（深入）”；
- 每个
__element必须有对应的.block__elementCSS规则，不能靠继承或全局重置 - 修饰符永远叠加在块或元素上（
block--mod或block__element--mod），不单独存在 - 用
@nest（PostCSS Nesting）写嵌套规则时，禁止写.block { &__element { ... } }以外的嵌套，否则生成的CSS选择器权重失控
遇到card__title card__title--large和card__title--small冲突怎么办
这不是BEM的问题，是CSS层叠顺序没管住。BEM只管命名，不管加载顺序。如果card__title--large在CSS里写在card__title--small后面，后者就会被覆盖——哪怕它在HTML里写得更靠前。
真正解法是放弃“哪个类名后写就生效”的直觉，改用构建时确定顺序：Webpack里用mini-css-extract-plugin确保card.css整体先于theme.css；或者直接用CSS Custom Properties做状态开关，把--title-font-size交给修饰符控制，而不是写两套字体大小规则。
- 同一块内多个修饰符互斥时（如
--large/--small），用JS控制类名切换，别同时挂载 - 不同块之间同名元素（如
card__title和modal__title）天然隔离，不用担心冲突 - 用
postcss-bem-linter检查是否意外写了.card .card__title这种非BEM选择器——它会破坏命名空间保护
要不要在React组件里用clsx拼BEM类名
要，但别滥用。像clsx('card', `card--${variant}`, {'card--loading': isLoading})没问题；但写成clsx(`card__${subEl}--${state}`)就危险——动态拼接破坏了静态可查性，IDE跳转失效，搜索card__footer找不到调用点。
BEM的价值在于“名字即契约”，一旦变成字符串模板，协作时就退化成普通类名。真正需要动态的部分（比如主题色）应该抽到CSS变量里，而不是塞进类名。
- 块名和元素名必须字面量（
'card__header'），修饰符可以条件拼接（`card--${size}`） - 用
useBem自定义Hook封装常用组合，比如useBem('card', { size, loading })，比裸写clsx更易维护 - 服务端渲染时注意
clsx结果要和客户端一致，否则Hydration mismatch——BEM类名必须完全静态可预测
__和--当分隔符，就得接受它带来的约束：不能偷懒缩写，不能跨块复用元素名，不能靠注释解释类名用途。这些地方卡得越死，后期改起来反而越快。 
