code review时可一眼识别class是否合规：直接看类名是否严格匹配block__element--modifier三段式结构，分隔符不可替换、顺序不可颠倒；如product-card__price--discount合规，而.title、card-title、button--primary--loading均违规。
Code Review时怎么一眼识别class是否合规
直接看类名是否严格匹配block__element--modifier三段式结构，分隔符不能替换、顺序不能颠倒。比如product-card__price--discount合规，而.title、card-title、button--primary--loading全部违规。
常见错误现象：
-
.title这种泛义名在CR里必须打回——它没声明归属块，后续任意地方加同名类都会意外覆盖 -
card-title缺双下划线，不是BEM；button--primary--loading是复合修饰符，违反“修饰符不可嵌套”原则 -
user_card混用单下划线，或user-card__item中block用短横线、element却用双下划线——工具链（如stylelint-selector-bem-pattern）无法识别结构，CI会漏检
BEM类名自带三层上下文，省去翻HTML验证
看到form-field__label--error，不用打开HTML就能确认：这是form-field模块里的label元素，当前处于error状态，样式只作用于该组件内。
对比传统写法：.error-label完全无法判断归属；.form .label.error依赖DOM层级，一旦结构微调就失效，Review时还得切到Elements面板反复验证。
关键约束点：
- 块名必须是业务语义词（
search-form✅，form❌） - 元素名不能单独出现（
__header非法，必须是modal__header） - 修饰符只描述状态（
--disabled✅，--bg-red❌）
哪些BEM违规必须在PR阶段拦截
这三类不是风格问题，而是直接影响可维护性的硬伤，人工review极易漏，必须由工具自动阻断：
- 修饰符单独使用：
class="button--loading"没带基础button类——删掉修饰符后样式完全丢失，违反BEM“modifier必须叠加在block或element上”原则 - 嵌套超限：
card__content__title__link暴露DOM路径而非语义，应改为card__title-link或提取link为独立block - 把具体值塞进类名：
button--width-200px——换单位或加媒体查询就得新增一堆类，违背修饰符只描述状态的原则
工具链怎么把BEM审查“焊死”在PR流程里
靠人工盯命名规则效率低还易漏，必须让机器在提交前拦截：
- VS Code安装
stylelint-config-bem插件，保存即高亮menu__item--active写成menu__item-active（少一个横线）这类错误 - pre-commit hook中运行
npx stylelint "**/*.scss" --fix，自动修正空格、大小写等低风险问题 - CI阶段执行
npx stylelint "**/*.{css,scss}" --max-warnings 0，任何BEM违规（如.card h3类型选择器）直接阻断合并
真正难检测的是语义越界——比如把一个按钮单独抽成button-group__item，实际它根本不属于button-group的DOM子树。这类问题无法靠正则捕获，得靠人眼结合组件边界意识判断。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
