BEM结构化CSS编写教程

BEM 不只是一套命名规则，而是通过 Block、Element、Modifier 三层结构为 CSS 注入清晰的语义上下文与强边界意识：每个 class 名都明确回答“它属于哪个独立模块、扮演什么角色、处于什么状态”，从而根治协作中“不敢改、不敢复用、不敢升级”的顽疾；它拒绝孤立的修饰符、严守嵌套层级、杜绝布局语义污染，并以“包裹+穿透”策略优雅整合第三方组件——真正让样式可预测、可追溯、可演进。

直接用 .btn 或 .card 写样式，很快就会在多人协作或迭代中失控——不是改不动，而是不敢动。BEM 的价值不在“看起来规范”，而在于让每个 class 名自带上下文：它属于哪个模块、扮演什么角色、当前是什么状态，三者全在名字里。

为什么 button--primary 不能 standalone 使用

BEM 中的修饰符（Modifier）必须依附于 Block，单独写 button--primary 会丢失语义锚点，导致样式被误复用或覆盖失效。比如一个弹窗里的按钮和用户列表里的操作按钮都用了 button--primary，但实际配色、圆角、阴影完全不同，却共用同一套 CSS 规则。

• 正确写法：user-list__action-button--primary 或 modal-header__close-button--primary
• 修饰符不表达布局或定位，--top-left 这类命名违反 BEM 原则，该交给 margin 或 grid-area
• 多个修饰符可自由组合：button--large button--disabled 是合法的，但 button--large-disabled 是反模式

__ 和 -- 写错一个字符，就等于没用 BEM

双下划线 __ 表示 Element（子元素），双短横 -- 表示 Modifier（修饰态）。写成单下划线 _ 或单短横 -，不仅破坏命名一致性，还会让团队成员无法快速识别层级关系，也容易和第三方库 class 冲突（如 el-button--small 是 Element Plus 自己的 BEM，你写成 button-small 就彻底失去隔离性）。

• 错误：header-logo、nav-item-active、card_content
• 正确：header__logo、nav-menu__item--active、card__content
• Element 必须是 Block 的**直接子元素**，card__content__title 是非法嵌套，应拆为 card__content + title__heading

第三方组件怎么套进 BEM 结构不打架

不要重写 .el-button 或 .ant-btn 的原始 class，那是自毁式维护。BEM 的解法是“包裹+穿透”：用你自己的 Block 包一层，再通过作用域限定向下控制。

• Vue SFC 场景：
  ，然后写 .user-form__submit ::v-deep .el-button { ... }
• Shadow DOM 或纯 CSS 场景：.user-form__submit .el-button { ... }，确保选择器只生效于该 Block 内部
• 绝对禁止：.el-button--primary { color: red; } —— 这会污染全局，且下次升级 UI 库时大概率崩

BEM 最容易被忽略的其实是“Block 边界感”：一个 Block 必须能独立存在、有明确语义、不依赖外部结构。写到一半发现要加 __ 却卡在“这到底算不算一个 Block”，往往说明这个组件职责已经模糊了——这时候该拆，而不是硬套命名。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。