BEM推广失败主因是评审标准不明确，需用stylelint+CI实现自动化校验，严格配置selector-bem-pattern规则、--max-warnings 0拦截、增量接入策略及JS中禁止动态拼接类名。
为什么BEM推广失败往往不是技术问题，而是评审标准不明确
团队说“支持BEM”，但代码里还满屏 .btn、.header、.active——根本原因不是没人学，是没人知道“什么算合规”。没有可量化的卡点，Code Review 就变成主观争论：“我觉得这个叫 user-card__avatar 比 card-avatar 好”，而不是“card-avatar 不符合 block__element 格式，stylelint 报错 plugin/selector-bem-pattern”。
用 stylelint + CI 实现“不合规范的代码无法合入”
靠人眼盯类名拼写，永远漏检。必须让工具在 PR 阶段就拦截。关键不是装插件，而是配置它识别你团队的真实约束：
- 在
.stylelintrc.js中启用stylelint-selector-bem-pattern插件，并严格限定 block 命名格式：module.exports = { plugins: ['stylelint-selector-bem-pattern'], rules: { 'plugin/selector-bem-pattern': { componentName: '[a-z][a-zA-Z0-9]+', styleType: 'bem' } } }; - CI 脚本中加入校验命令：
npx stylelint "**/*.{css,scss,less}" --max-warnings 0 - 注意两个细节：
--max-warnings 0把 warning 当 error，避免“先 merge 再修”的侥幸；路径通配符要覆盖所有样式文件后缀，老项目若混用.styl或.pcss，必须显式加上 - 本地开发时，VS Code 安装 Stylelint 插件并启用 auto-fix on save，让问题在编码阶段暴露
老项目怎么增量接入，又不让开发停工
全量重命名等于停摆一周，没人会执行。可行路径是守住新增、收敛旧边界、不推倒重来：
- 新功能、新组件、修改过的组件必须遵守 BEM；老代码保留，但禁止在已有非 BEM 类上新增修饰逻辑
- 用
postcss-bem-linter在 CI 阶段校验新增 CSS 是否符合 BEM 规则，只扫src/components/**/*.{css,scss}这类新增路径 - 对全局重置类（如
.clearfix、.sr-only）豁免 BEM，但需单独归档到base/目录并加注释说明用途 - 遇到
.user-list .item和.user-list__item并存时，立刻冻结旧写法：在 ESLint 中加规则禁止出现空格分隔的选择器，直接报错
React/Vue 项目里怎么写才不破坏 BEM 完整性
BEM 类名一旦被 JS 动态拼接或条件覆盖，就脱离了 CSS 文件的静态定义，调试时 DevTools 里看到的类名和源码对不上，hydration mismatch 风险陡增：
立即学习“前端免费学习笔记（深入）”；
- 禁止手写模板字符串：
className={`button ${isDisabled ? 'button--disabled' : ''}`}→ 改用clsx：className={clsx('button', { 'button--disabled': isDisabled })} - 禁止动态构造类名：
${block}__${elem}--${mod}→ 所有 BEM 全称必须硬编码，不从 props 构造__或--部分 - React 组件顶部定义常量：
const BLOCK = 'search-bar'，所有类名基于它派生，避免 JSX 里写死search-bar__input而 CSS 里写成.searchBar__input - Vue 3 的
:class可直接绑定对象：:class="{ 'modal__overlay--visible': visible }"，但需确保modal__overlay在 CSS 中已声明基础规则
block__element 的正则校验焊进保存和提交环节，BEM 就只是文档里的一行字。 
