bem是block element modifier命名规范，非管理方法论；其落地效果应通过类名一致性、协作效率及工具链拦截违规来评估，而非css代码审计。
不能用 CSS 代码审计来评估 BEM 在项目中的实施效果。
BEM 是 Business Execution Model 或 Behavior Engineering Model 的缩写，属于战略解码、绩效诊断类管理方法论；而前端开发中常说的 BEM 是 Block Element Modifier 命名规范——两者同名异物，领域、目标、产出物完全无关。拿 CSS 审计去衡量“战略是否落地”或“员工行为是否改变”，就像用万用表测水温。
真正该问的是：团队写的类名，是否符合 block__element--modifier 这一约定？是否在协作中减少了歧义和冲突？
怎么判断 BEM 是否在项目里“真落地”了
不是看有没有 .header__logo--dark，而是看它是否被一致使用、能否支撑快速协作：
- 审查元素时，看到
user-card__title和user-card-title并存，说明标准没对齐 - 设计师说“把所有主按钮变大”，结果有人改
.button--large，有人加.btn-lg，还有人直接写button { font-size: 1.2em }，说明语义没收敛 - 组件库升级后，
modal__close突然失效，因为新版本用了modal__trigger--close，但没人同步更新 HTML —— 这暴露了修饰符变更缺乏契约意识
用工具链验证 BEM 执行是否稳定
靠 Code Review 拦不住手滑。必须让违规类名在保存、提交、构建环节就被拦截：
- 用
stylelint-selector-bem-pattern插件，配置{ "componentName": "[a-z][a-zA-Z0-9]+", "styleType": "bem" }，自动报错.header .logo或.btn-primary - CI 流程中跑
npx stylelint "**/*.{css,scss}"，失败则阻断合并 - 禁止在 JS 中拼接类名：
className={`card__body ${isCollapsed ? 'card__body--collapsed' : ''}`}改为用cn('card__body', { 'card__body--collapsed': isCollapsed })（配合clsx）
为什么不能只看“类名格式对不对”
格式合规只是底线，真正的实施效果体现在协作成本上：
-
product-card__title--highlighted这种名字本身已含归属（product-card）、角色（__title）、状态（--highlighted），别人不用翻 HTML 就能理解意图 - 如果 PR 里频繁出现
card-title和card__title混用，说明团队还没形成“类名即文档”的共识 - 当新人能凭类名快速定位样式来源、修改不破坏其他模块，才叫 BEM 落地了——不是语法正确，是语义可传递
真正难的不是写对 __ 和 --，而是让所有人相信：一个长类名，比五个短类名加注释，更能降低沟通成本。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
