BEM类名写错一个下划线就导致工具链失效，因其解析逻辑完全依赖__和--作为唯一分隔符；user_name会被误判为块user+元素name，card-element被当作普通块名，stylelint、PostCSS插件及VS Code BEM Helper均无法识别结构，正则匹配失败后直接跳过校验。
为什么BEM类名写错一个下划线就导致工具链失效
BEM的解析逻辑完全依赖__和--作为唯一分隔符。写成user_name或card-element，stylelint、postcss-bem-linter、VS Code的BEM Helper插件都会无法识别结构——它不是“差不多就行”，而是正则匹配失败后直接跳过校验。
常见错误现象：
-
user_name被误判为块user+元素name，但name根本不是user块的合法元素 -
card-element被当作普通块名，无法提取element层级，CI阶段直接报Unexpected BEM structure - VS Code的Auto Rename Tag插件只监听
__/--模式，改header__logo不会同步更新header-logo对应CSS
为什么.btn在多人项目里必然失控
CSS没有作用域，.btn是全局的。它可能来自reset.css、header.scss、modal组件、第三方UI库，甚至某人随手写的div.btn。没人能单凭类名判断归属。
BEM把归属直接编码进名字：.nav__btn、.form__submit-btn、.carousel__control-btn，三者互不干扰，也不依赖DOM层级。
立即学习“前端免费学习笔记（深入）”；
实际协作中，最常踩的坑是“伪BEM”：class="card card--featured"，但CSS里只写了.card--featured，漏了基础块样式。结果删掉--featured，整个card就崩了——BEM要求所有修饰符必须和基础块共存。
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
为什么团队新人三分钟就能看懂header__logo--dark
因为名字本身携带了层级意图和状态语义：header是块，logo是它的元素，dark是该元素启用的变体。不用翻JS或HTML就能猜出作用范围。
实操依赖两个硬约束：
- VS Code装
Auto Rename Tag插件后，改class="card__content"会同步更新对应CSS里的.card__content - 配
stylelint-config-bem，保存时立刻报错：Unexpected BEM element name "card__content-inner"，说明你嵌套太深，该拆块了 - 禁止在修饰符里塞具体值，比如
button--width-200px——这违反“修饰符描述状态而非样式”的原则，后续换单位或响应式时就卡住
为什么老项目增量接入BEM最卡在类名混用
全量重命名不现实。真正崩坏点在于新旧类名并存：.user-list .item和.user-list__item同时存在，开发者无法判断该用哪个，最终谁手快谁提交，规则形同虚设。
策略核心是停止新增非BEM类名：
- 新功能、新组件、修改过的组件强制用BEM
- 遗留代码不动，但禁止在老模块里新增
.float-left这类工具类 - 用
stylelint-selector-bem-pattern配置strict模式，在保存时立刻报错：Unexpected selector ".user-card h3" - 对全局重置类（如
.sr-only、.clearfix）豁免BEM，但必须归档到base/目录并加注释说明用途
真正难的不是写出block__element--modifier，而是让团队在加一个tooltip时，本能地新建/components/tooltip/目录，而不是往modal.css里塞.modal__tooltip——这需要目录结构契约、CI检查、以及最初几个模块的示范性实现。
