直接改类名会引发全局样式污染，因为CSS无作用域，泛化类名（如btn、content）在全局竞争，导致多模块相互干扰；BEM通过唯一block名、双下划线元素名、双短横修饰符明确归属与语义，解决命名冲突与维护混乱。
为什么直接改类名会引发全局样式污染
改一个 .btn 类，结果登录页的提交按钮变宽、后台表格的操作列对齐错乱——这不是偶然。CSS 没有作用域，所有类名都在全局竞争；一旦多个模块共用 btn、list、header 这类泛化名，重构时根本分不清谁在影响谁。
真实项目里，.content 可能同时出现在文章页、弹窗、侧边栏，而开发者只记得“自己写的那个”。BEM 不是加前缀炫技，是让类名自带上下文：谁属于谁、起什么作用、有没有修饰状态。
-
block名必须唯一且语义明确（如product-card，而非card） - 元素名用双下划线
__连接，禁止嵌套层级（product-card__title✅，product-card__header__title❌） - 修饰符用双短横
--，只表达状态或变体（product-card--featured），不写样式细节（product-card--blue-bg是反模式）
如何把旧 CSS 快速映射到 BEM 结构
别重写整套样式表。先锁定高频冲突模块（比如 header、modal、form-item），按组件边界切块，再逐个升级 HTML 和对应 CSS。
关键动作不是“改名”，而是“绑定归属”：原来散落的 .input、.input-error、.input-label 全部归入 form-item 块下，变成 form-item__input、form-item__input--error、form-item__label。
立即学习“前端免费学习笔记（深入）”；
- HTML 中每个块级容器加
block类（如<div class="form-item">） <li>CSS 里删掉所有孤立的 <code>.input规则，只保留.form-item__input及其修饰符 - 避免用后代选择器模拟 BEM（
.form-item .input❌），它破坏可预测性，也阻碍未来用 CSS Modules 或 Shadow DOM - 若用 PostCSS，推荐
postcss-bem插件自动补全嵌套写法（但别依赖它生成全部类名，易失控） - Vite 项目中，BEM 类名可配合
unocss的自定义规则复用，但需禁用其默认的原子类匹配，否则flex、text-center会误伤 BEM 块名 - 注意
display: contents或visibility: hidden容器可能让 BEM 的 DOM 层级失效，此时需用aria-hidden或注释说明结构意图 - 新组件强制要求写
block名，旧组件用“渐进式标注”：先加data-block="xxx"注释用途，再逐步替换类名 - CI 流程中加简单校验（如正则
/\.[a-z]+__[a-z]+/），不拦截，只告警未按 BEM 命名的新提交 - 设计师给的 Sketch 文件里若写的是
btn-primary，前端实现时得立刻翻译成button--primary，而不是照抄——后缀语义必须对齐，否则开发和设计对不上
BEM 与现代构建工具怎么不打架
Webpack 的 css-loader 开启 modules 后，默认类名哈希化，BEM 看似多余？其实不然。BEM 解决的是人协作时的理解成本和维护路径，而 CSS Modules 解决的是运行时作用域。二者叠加才真正防崩：BEM 让你一眼看懂 user-profile__avatar--large 是哪个模块的哪个部分，CSS Modules 确保它不会被另一个 avatar--large 覆盖。
团队落地 BEM 最容易卡在哪一步
不是语法记不住，是老代码里一堆 div class="clearfix"、span class="red" 这类纯样式类，它们既不属于任何 block，又到处复用。这类“幽灵类”必须统一收口：要么转成 BEM 修饰符（button--danger 替代 red），要么抽成 utility 类并加命名空间（u-text-danger），绝不能混在 block 内部。
最麻烦的永远不是命名规则本身，而是那些没被显式声明的隐含依赖：某个 margin-top: -20px 正好抵消了父容器的 padding，一改成 BEM 就露馅。这种地方得靠视觉回归测试兜底，别信“看起来没变”。
