直接用 class 名会出事是因为 CSS 无作用域，class 冲突由加载顺序和特异性决定，导致样式覆盖、构建错乱等问题；根本原因是 class 泛化、缺乏上下文绑定。
为什么直接用 class 名会出事
CSS 没有作用域，.button 在哪定义、在哪用，全看顺序和权重。两个组件都写 .icon，一个设 color: red，另一个设 color: blue，最后谁赢取决于 CSS 加载顺序或选择器特异性——不是你写的逻辑决定的，是浏览器“碰巧”算出来的。
常见错误现象包括：
- 修改 A 组件样式，B 组件的按钮突然变小
- 第三方 UI 库升级后，自己写的
.header被覆盖成圆角阴影 - 本地开发正常，构建后（CSS 提取合并）样式错乱
根本原因不是“写错了”，而是 class 名太泛、没绑定上下文。
BEM 的三要素怎么对应到真实文件结构
BEM 不是命名癖好，是把组件边界显式写进 class 名里：block__element--modifier。关键在 block 必须唯一且语义闭环。
立即学习“前端免费学习笔记（深入）”；
比如一个用户卡片组件，推荐这样组织：
user-card/ ├── user-card.css ├── user-card.js └── user-card.html
所有 class 都以 user-card 开头：
- 根容器：
user-card - 头像区域：
user-card__avatar - 昵称文字：
user-card__name - 禁用态：
user-card--disabled
注意：
-
__前后必须紧贴名称，不能写成user-card _avatar或user-card__ avatar - 修饰符
--只用于状态/变体，不用于布局类（比如别写user-card--flex） - 不嵌套 BEM 块，
user-card__avatar里面再塞一个独立组件（如status-indicator），就用它的完整 block 名，不缩写
和 CSS Modules / scoped CSS 比，BEM 什么时候更合适
BEM 是纯约定，不依赖构建工具；CSS Modules 是编译时加哈希，scoped CSS（如 Vue SFC）靠属性选择器隔离。它们解决的问题重叠，但约束点不同。
适用 BEM 的典型场景：
- 项目用原生 HTML + 手动引入 CSS，没法跑 Webpack/Vite
- 需要 SSR 渲染且服务端不跑 JS（比如 PHP 模板直出），无法生成动态 class
- 团队里有非前端人员维护部分模板（运营页面、CMS 插件），他们只改 HTML，不碰构建配置
容易踩的坑：
- 在启用了 CSS Modules 的项目里还手动写
user-card<strong>title</strong>，结果样式没生效——因为实际生成的是类似user-cardtitle_abc123，你写的 class 名对不上 - 把 BEM 当万能解药，给每个 div 都套三层命名，反而让 HTML 膨胀、可读性下降；BEM 只应在组件级抽象，不是原子级
如何用自动化工具守住 BEM 规则
人总会手滑。比如不小心写了 user-card<strong>name--large</strong>（元素带修饰符），或者在 header 组件里用了 user-cardavatar 这种跨块引用。
推荐两个轻量方案：
- ESLint 插件
stylelint-selector-bem-pattern，配规则强制匹配^[a-z][a-zA-Z0-9]<em>(__[a-z][a-zA-Z0-9]</em>)?(--[a-z][a-zA-Z0-9]*)?$ - VS Code 安装插件
Auto Rename Tag，配合 BEM snippets（比如输入uca自动展开为<div class="user-card__avatar">） <p>性能上无影响，但能卡住最常犯的两类错误：块名不一致、元素/修饰符层级错乱。</p> <p>BEM 的复杂点不在语法，而在于团队是否对“什么算一个 block”有共识——比如 <code>search-input和search-form是两个 block，还是后者包含前者？这种边界判断，比写对双下划线难得多。
