bem让code review从“猜意图”变为“看名字”，因类名结构（block__element--modifier）直接表明归属、角色与状态，审查者无需上下文即可判断修改影响范围；禁止修饰符单独使用、禁用视觉词命名、严控嵌套层级，并通过工具链自动校验三类高危违规。
代码审查时，BEM不是用来挑缩进或大小写的，而是快速判断「这个样式改得对不对、影响范围清不清楚」——只要类名结构合规，90%的样式污染和误覆盖问题在CR阶段就能被一眼识别。
为什么BEM能让Code Review从“猜意图”变成“看名字”
传统审查中，看到 .btn--large 得翻HTML确认是不是全局按钮，看到 .title 得查上下文怕动了别处的标题。BEM把语义直接编码进类名：header__logo--dark 明确表达三层信息：属于哪个块（header）、是块内哪个元素（logo）、当前什么状态（dark）。审查者不用点开文件、不用问人，光看类名就能判断：这个修改只影响 header 模块里的 logo，且仅限 dark 变体。
常见错误现象：card .title 这种写法在CR里必须打回——它没声明 title 属于哪个 block，后续任何地方加个 .title 都可能意外覆盖；又或者 button--blue 被接受，但“blue”是颜色值而非状态，下次主题切换就得全量搜索替换。
-
block名必须是业务语义词（如product-card），禁用视觉描述（如blue-button） -
__element名只反映角色（__actions），不体现位置（__top-actions是错的） -
--modifier必须是布尔态或有限枚举（--disabled、--expanded），不能是具体值（--width-200px）
Code Review时重点盯哪三类BEM违规
BEM本身不防错，但三类典型违规会直接放大维护风险，CR阶段必须拦截：
- 类名里混用单下划线或短横线：
user_card或user-card__item——工具链（如stylelint-bem-naming）无法识别结构，CI 会漏检 - 修饰符单独使用：
class="button--loading"而没带基础块button——删掉修饰符后样式崩塌，违反 BEM “修饰符必须叠加在块或元素上” 原则 - 嵌套层级超限：
card__content__title__link——这暴露了 DOM 路径而非语义，应改为card__title-link或拆出新 block（如link）
这些不是风格偏好，而是直接影响可维护性：第一类让自动化校验失效，第二类导致运行时不可预测，第三类让重构成本指数级上升。
如何用工具把BEM审查变成自动卡点
靠人工盯命名规则效率低还易漏，必须把校验塞进开发流程里：
- VS Code 安装
stylelint-config-bem插件，保存即报错：Unexpected BEM element name "card__header-inner"表示嵌套过深 - CI 阶段跑
postcss-bem-linter，新增 CSS 文件若含.user-list .item这类非BEM选择器，直接阻断合并 - 组件文档强制要求每个 block 开头加注释块，例如：
/* @block product-card @modifiers: --featured, --compact */——CR时对照注释检查新增修饰符是否已登记
工具只管格式，但人要管意图：比如 button__icon--small 语法合法，但图标尺寸不该由 button 控制，应交由 icon 自身的 icon--small 处理——这种跨职责耦合，只能靠审查者结合业务逻辑判断。
BEM在Code Review里真正的价值，不是让名字变长，而是把“这个样式改了会影响谁”的不确定性，压缩成一个可验证的字符串结构。最常被忽略的是：修饰符必须和基础类共存，以及所有 __element 必须有对应CSS规则——这两条不满足，再规范的名字也救不了运行时的样式雪崩。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
