前端BEM规范：说服团队统一css代码风格

背景

在我负责建设移动端组件库的前期，发现团队对 JS/TS 代码规范的重视，往往远超 CSS/SCSS。但在当前这种UI体系的“样式驱动”项目中，CSS 规范的缺失会带来极大的维护成本和协作障碍。BEM（Block-Element-Modifier）规范，是解决这一痛点的最佳实践之一。

---

为什么 JS/TS 规范普及，CSS 却常被忽视？

• 工具链完善：JS/TS 有 ESLint、Prettier、TSLint 等工具，团队易于统一风格。
• 影响直观：JS/TS 规范不统一，编译/运行直接报错，影响开发效率。
• CSS 问题隐蔽：样式冲突、命名混乱、全局污染等问题，往往在多人协作或后期维护时才暴露。
• 组件库场景下更易失控：样式复用、隔离、状态扩展等需求极高，命名不规范极易导致“蝴蝶效应”。

---

什么是 BEM 规范

BEM（Block-Element-Modifier）是一套结构化的 CSS 命名方法论：

• Block：独立的功能块（如 .ai-checkbox）。
• Element：块的组成部分（如 .ai-checkbox__icon）。
• Modifier：块或元素的修饰状态（如 .ai-checkbox--disabled）。

真实代码示例（移动端多选框组件样式文件）：

.ai-checkbox {
  display: flex;
  // ...existing code...
  &__icon {
    // ...existing code...
    &.ai-checkbox--round { border-radius: $ai-radio-border-radius-max; }
    &.ai-checkbox--checked { .ai-icon { color: $ai-radio-text-color-active; } }
    &.ai-checkbox__icon--disabled { cursor: not-allowed; opacity: 0.8; }
  }
  .ai-checkbox__label { ... }
  .ai-checkbox__tag { ... }
}

---

BEM 规范的优势

1. 命名清晰，职责分明

• 一眼看出类名属于哪个组件、哪个部分、什么状态。
• 新成员、或者后期维护者都能快速理解和定位。

2. 样式隔离，避免冲突

• BEM 类名天然具备作用域，极大降低全局污染和样式覆盖风险。
• 组件库场景下，保证每个组件的样式独立、可复用。

3. 易于维护和扩展

• 新增、修改、删除样式时，定位精准，影响面可控。
• 支持多状态、可组合，适合复杂交互和多样化需求。

4. 降低沟通和协作成本

• 统一命名规范，减少“你这个类名是干嘛的？”、“为啥样式被覆盖了？”等低效沟通，使团队能无障碍协作。

---

推动 BEM 规范在团队落地

• 组织分享会，展示实际样式冲突、维护困难的案例，让团队感受到痛点。

• 将 BEM 作为团队 CSS 命名规范，写入开发手册，配合代码示例。

• 样式类名不符合 BEM 的代码不予合入，评审时重点关注。

• 每个组件文档中明确列出 BEM 类名结构，便于新成员理解和复用。

---

BEM 不是唯一的 CSS 规范，但它是比较适合多人协作、组件化开发的命名方法之一。作为组件库负责人，我强烈建议团队像重视 JS/TS 一样重视 CSS，让每一行样式都可维护和复用，真正做到高质量、易扩展、可持续。