BEM本身不降低门槛，但配合文件命名对齐、编辑器自动补全、禁止字符串硬编码可让新人5分钟内写出合法类名；常见错误包括边界不清（如.header-menu-item）、状态类无挂载目标（如.is-active）、修饰符非原子化（如.card__title--large）等。
直接结论：BEM 本身不降低门槛，但配合文件命名强制对齐、编辑器自动补全、禁止字符串硬编码这三件事，能让新人打开项目 5 分钟内写出合法类名。
为什么新人一写就错？常见错误现象
新人写的 .header-menu-item 看似合理，实际破坏了 Block 边界——menu 和 item 谁是块？无法判断；.is-active 这类纯状态类没挂载目标，CSS 选择器失效后连 console 都不报错；更隐蔽的是 .card__title--large，把尺寸当修饰符，结果换主题时要全局搜 --large 替换，而不是改一个 --compact 枚举值。
这些不是粗心，是缺乏即时反馈机制：没有工具提示“card__title--large 不符合修饰符原子化原则”，也没有模板告诉ta“这里该填什么”。
- 双下划线
__和双短横--混用（如card--title）会导致构建工具校验失败 - 块名必须小写+连字符，
SearchForm或searchForm在 CSS-in-JS 环境中无法提取作用域 - Element 名禁用 HTML 标签名：
card__div❌，应写card__content✅
VS Code 里怎么让 BEM 变成“填空题”
安装 bem-tools 插件后，输入 bem 触发 snippet，自动补全为 block__element--modifier 框架；再自定义 snippet，键入 elem → 输出 block__${1:element}，光标停在 element 位置，避免手敲漏掉一个下划线。
立即学习“前端免费学习笔记（深入）”；
关键不是功能多，而是堵死自由发挥路径：
- 组件顶部声明常量：
const BLOCK = 'modal';，后续所有类名基于它派生：${BLOCK}__header、${BLOCK}--fullscreen - 禁止在 JSX 中出现任何未经过
BLOCK派生的字符串，如'modal__close'必须写成${BLOCK}__close - ESLint 插件
eslint-plugin-css-modules校验：若当前文件是Button.module.scss，则只允许button开头的类名出现在className中
老项目补 BEM 最容易踩的三个坑
别一上来就全局搜索替换 .card → .card__root。真正卡住新人的是“改一半”：
- 只改子元素类名（如加了
.card__title），却保留旧的.card根类，导致新旧样式并存、特异性冲突 - 把修饰符挂在 Element 上（
.card__title--disabled），而没同步加.card--disabled控制整体状态，JS 切换 class 时逻辑断裂 - 和第三方组件库硬刚：直接覆盖
.el-button，结果升级 Element Plus 后样式崩，且污染全局；正确做法是封装 wrapper：<div class="my-button"><el-button class="my-button__inner">提交</el-button></div>
React + CSS Modules 下 BEM 失效的真实原因
很多人以为开了 CSS Modules 就自动 BEM 安全，其实不然。开发者 import styles from './Button.module.scss' 后，随手写 className={styles.icon}，但文件里压根没定义 icon，只有 button__icon —— 这就绕过了 Block 边界。
必须做两件事：
- 组件只暴露 Block 类名：
styles.button，Element/Modifier 全部通过组合注入，比如<button icon="left"></button>渲染出button button--icon-left button__icon - 禁用字符串拼接：
className={`button ${props.active ? 'button--active' : ''}`是反模式，必须用clsx统一处理，且所有参数都基于BLOCK派生
最易被忽略的点是：BEM 的约束力不在命名规则本身，而在构建时是否能拦截非法引用。比如 _button.scss 里写了 .modal__close，这个跨 Block 引用必须被 lint 拦住，否则新人根本意识不到自己已经越界。
