bem是命名约定而非新语法，核心为三原则：双下划线__分隔块与元素、双中划线--表示状态修饰符、所有类名扁平无层级依赖；不用嵌套选择器因其隐含dom结构假设，易因html调整导致样式失效，而bem类名自带语义与作用域，保障稳定性。
什么是BEM，为什么不用嵌套选择器直接写
BEM（Block Element Modifier）不是新语法，是命名约定，核心就三条：用双下划线 __ 隔开块与元素，用双中划线 -- 表示状态修饰符，所有类名都扁平、无层级依赖。
不用嵌套选择器（比如 .card .title）是因为它隐含了 DOM 结构假设——一旦 HTML 微调（比如加个包裹 div），样式就断；而 BEM 类名自带语义和作用域，.card__title 永远只属于 card 块内部，跟父级是谁无关。
常见错误现象：.header ul li a 这种“路径式”写法，后期改结构时总得同步修 CSS，团队协作里尤其容易漏改。
怎么给一个按钮组件写合规的 BEM 类名
以按钮为例，“主按钮带图标”这个场景下，不能只写 .btn 或 .button--primary 就完事，得明确 Block、Element、Modifier 三层关系：
- Block 是独立可复用单元：用
.btn - Element 是它内部的子部分：图标就是
.btn__icon，文字是.btn__text - Modifier 描述变体：尺寸大一点是
.btn--large，禁用状态是.btn--disabled，可叠加使用（.btn--large.btn--disabled）
.btn--large 合理，.btn__text--large 就越界了——字体大小是整个按钮的视觉变体，不是文字元素自身的状态。
遇到嵌套深的组件（比如表单里的输入框+提示+错误态），BEM 怎么避免类名爆炸
深层嵌套不等于要写长串类名。关键原则是：每个视觉上可独立存在的 UI 单元，都应是一个 Block。
比如表单中一个带校验的输入区，别硬塞进 .form__field__input__error，而是拆成两个 Block：
-
.input-field（负责布局、边框、label 容器） -
.input（纯输入控件本身，含.input__element和.input--error） - 错误提示单独成块：
.validation-message，用.validation-message--error控制样式
.validation-message 相关规则，不影响 .input-field 的任何逻辑。
用 PostCSS 或 SCSS 写 BEM 时，哪些语法糖会埋坑
SCSS 的 & 符号看着方便，但容易写出违反 BEM 扁平原则的代码：
.btn {<br> &__icon { … }<br> &--large { … }<br> // ✅ 合规<br><br> .btn__text {<br> &--highlighted { … }<br> }<br> // ❌ 错误：.btn__text--highlighted 应该是 .btn--highlighted 或另起 Block，这里用嵌套生成了非法结构<br>}
PostCSS 的
postcss-bem 插件能强制约束，但默认配置可能允许 element-modifier（如 .btn__text--bold），这不符合官方 BEM 指南——Modifier 只作用于 Block 或 Element 本身，不作用于子元素的状态。真正省心的做法：不用预处理器生成类名，手写类名 + ESLint 或 stylelint 插件校验（如
stylelint-selector-bem-pattern），比依赖语法糖更可靠。
最常被忽略的一点：BEM 不解决样式隔离，它只管命名。如果用 CSS Modules 或 Shadow DOM，BEM 类名依然要写，但作用域已由工具保障；如果纯全局 CSS，那 .btn 还是可能被其他库或老代码污染——命名规范只是第一步，得配合构建层策略才真正模块化。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
