bem通过唯一性前缀隔离作用域避免样式冲突,而非依赖!important;其核心是块(block)、元素(__)、修饰符(--)三层命名规范,强制语义化、解耦与团队协作一致性。

为什么BEM能避免样式冲突而不是靠!important
因为BEM强制用唯一性前缀隔离作用域,button--primary 和 modal__header 天然不会互相影响,不用靠覆盖优先级硬拼。CSS权重混乱的根源是选择器泛化——比如写个 .title,谁都能改;而 card__title 只属于 card 这个块,改它得先找到对应块文件。
- 别在BEM里嵌套过深:
.card .card__header .card__header-title是错的,应写成card__header-title,BEM不依赖DOM结构层级 - 修饰符(
--)只用于同一块的变体,比如button--disabled,不是用来表达“子组件状态”的 - 元素(
__)名必须语义化,card__img比card__el-1强十倍——否则重构时根本猜不出它干啥
怎么把现有CSS迁移到BEM而不炸掉页面
直接全局搜替换 .btn → .button 会出事。BEM迁移本质是“重命名+解耦”,不是字符串替换。
- 先加新类:给按钮同时写
class="btn button button--primary",旧JS仍能通过.btn找到节点,新样式走BEM - 逐步删旧类:等所有相关JS、测试、视觉回归都确认无误,再移除
.btn - 注意第三方UI库:像
ant-design或element-plus自带类名,别强行套BEM,用它们的定制主题机制更稳妥
伪类和响应式在BEM里怎么写才不乱
BEM本身不管伪类和媒体查询,但写法松散就容易破坏命名一致性。关键不是“能不能写”,而是“写在哪、怎么命名”。
- 伪类保持在同一层级:
button--primary:hover合理,button__icon:hover也合理;但别写button:hover__icon——语法错误,且逻辑错位 - 响应式修饰符加后缀:
card--sm-up表示“小屏及以上生效”,比散落各处的@media (min-width: 480px)更易追踪 - 慎用
:not():BEM鼓励显式命名,button:not(.button--disabled)不如直接定义button--enabled,后者可复用、可文档化
遇到动态类名或CSS-in-JS还用BEM吗
用,而且更需要。动态生成类名时,BEM是防止命名随机化的最后一道防线。
- 模板字符串里拼接要严格守规:
className={`card__content card__content--${size}`},别写成card-content-${size} - CSS-in-JS 如
styled-components,仍建议用BEM风格命名导出的组件:const CardHeader = styled.div`...`; CardHeader.displayName = 'card__header'; - 服务端渲染要注意:BEM类名必须和客户端完全一致,否则React会报
Prop `className` did not match
真正难的不是写对一个 form__label,而是所有人持续遵守同一套前缀规则。团队里只要一个人开始写 userCardTitle,BEM就从内部瓦解了。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











