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就从内部瓦解了。
