bem 的 class 名看似冗长实为解耦样式作用域，强制采用 block__element--modifier 结构以明确作用域和语义，需配合扁平选择器、禁用嵌套与通用类，并在现代方案中转化为命名逻辑或模块锚点。
为什么 BEM 的 class 名长得像加密字符串？
因为 BEM 强制用 block__element--modifier 这种结构，不是为了炫技，而是为了解耦样式作用域。当多个开发者同时改 .header 时，没人知道谁在覆盖谁；但换成 site-header__logo--large，一眼就锁定作用域和语义——它只属于 site-header 这个块，且只影响 logo 元素的“大尺寸”状态。
常见错误是把 BEM 当命名习惯用，却没配合 CSS 作用域控制：比如在全局写 .btn--primary，结果被第三方 UI 库的 .btn 规则意外命中。BEM 真正生效的前提，是所有选择器都严格遵循层级扁平原则——不依赖嵌套，不写 .card .card__title，只写 .card__title。
- 所有样式必须基于 block 名开头，禁止使用标签名或通用类（如
div、.clearfix）作为选择器主体 - 元素（
__）和修饰符（--）不能脱离 block 单独存在；.menu__item--active合法，.menu-item--active违规 - 嵌套 Sass/Less 时，用
&__element而非& .element，否则编译后会多出空格，破坏 BEM 语义
CSS-in-JS 或 Tailwind 下，BEM 还有必要吗？
有必要，但角色变了。在 styled-components 中，你不需要手写 user-card__avatar，因为组件封装天然隔离样式；但团队仍需约定命名逻辑——比如用 Avatar 作为元素名，size="large" 对应 --large 修饰符，底层生成的 class 依然隐含 BEM 意图。
Tailwind 是另一回事：class="flex items-center p-4 bg-gray-50 rounded-lg" 看似和 BEM 冲突，实则互补。BEM 告诉你“这是哪个模块的哪个状态”，Tailwind 告诉你“它长什么样”。二者常共存于同一项目：用 BEM class 定义区块边界（product-list），再用 Tailwind class 控制内部表现。
- 纯 CSS-in-JS 项目可弱化 class 字符串，但组件接口 props 设计（如
variant、size）要映射 BEM 修饰符逻辑 - Tailwind 用户容易忽略语义层，导致 HTML 里满屏 utility class，搜索定位困难；建议保留一个 BEM class 作为模块锚点，例如
<div class="product-card bg-white">...</div> - 构建工具如
postcss-bem可自动补全 BEM 前缀，但需警惕它把.button:hover错误转成.button__hover——修饰符只用于静态状态，伪类不算
如何让设计师和前端对齐 BEM 命名？
靠文档没用，得进工作流。Figma 插件如 Design Token Manager 允许给图层命名加前缀（btn/primary），导出时自动转成 btn--primary；前端用 style-dictionary 把设计系统 JSON 同步为 BEM 友好变量，比如 {"colors": {"primary": "#007bff"}} → 生成 $color-primary: #007bff 和对应 class theme--primary。
最容易崩的是修饰符翻译：设计师说“暗色模式”，前端可能写成 dark、night 或 inverted。统一用 --dark，并在 PR 检查中加入正则校验：/--(light|dark|disabled|hover|focus)/。
- 命名词典必须包含“禁用词”，例如禁止用
big/small，强制用--lg/--sm（与设计系统字号 scale 对齐） - 视觉稿标注需明确区块层级：标出哪个是 block（如
search-form），哪些是它的 element（search-form__input、search-form__submit） - CI 流程中跑
stylelint-selector-bem-pattern，对不符合规则的 class 报错，不通过 PR
modal 还是 dialog，但一旦定错，后续所有 __ 和 -- 都会漂移。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
