BEM通过块__元素--修饰符命名结构实现类名空间化，避免全局冲突与误覆盖，提升多人协作可追溯性与维护效率。
为什么BEM能减少CSS类名冲突和维护成本
团队多人协作时，.header、.btn 这类泛用类名极易被重复定义或意外覆盖。BEM强制拆解为 .block__element--modifier 结构，本质是用命名空间替代CSS作用域——浏览器不支持局部作用域，那就靠人写得“不撞车”。它不解决样式复用问题，但把“谁改了哪个按钮”变成可追溯的字符串组合。
常见错误现象：.user-card .avatar 被另一个模块的 .avatar 全局重置；修改 .btn 后，登录页和弹窗里的按钮同时错位。
- 必须严格对应组件结构：一个
.card组件里所有子元素类名都以card__开头，不能出现.card .title - 修饰符（
--）只用于状态变化，如.button--disabled，不用于描述视觉差异（比如--blue就容易失控） - 避免嵌套层级：BEM不是让你写
.card__content__title__link，而是.card__title-link—— 元素名应反映语义，不是DOM路径
BEM在React/Vue项目中怎么落地不反人类
框架组件天然有作用域，但BEM的价值不在“防污染”，而在“跨组件沟通”。当UI库、业务组件、老代码混用时，统一命名让开发者一眼看懂类名归属。
使用场景：组件库交付给其他团队、SSR服务端渲染需复用class逻辑、用jest做快照测试时比对class是否稳定。
立即学习“前端免费学习笔记（深入）”；
- React推荐用
clsx拼接：className={clsx('button', { 'button--loading': loading })}，别手写模板字符串 - Vue 3 的
:class可直接绑定对象：:class="{ 'modal__overlay--visible': visible }" - 禁止在JS里硬编码BEM字符串，比如
el.classList.add('card__body')—— 应该抽成常量或工具函数，否则重构时漏改一处就埋雷
遇到 legacy CSS怎么办：渐进式迁移策略
全量重命名不现实，重点不是“改成BEM”，而是“不再新增非BEM类名”。老代码保留，新功能、新组件、修改过的组件必须遵守。
常见错误现象：迁移一半后出现 .user-list .item 和 .user-list__item 并存，开发者无法判断该用哪个。
- 用PostCSS插件
postcss-bem-linter在CI阶段校验新增CSS是否符合BEM规则 - 在SCSS中用
@at-root避免嵌套污染：.card { @at-root .card__header { ... } }，而不是靠缩进模拟结构 - 对全局重置类（如
.clearfix、.sr-only）豁免BEM，但需单独归档到base/目录并加注释说明用途
别让BEM变成新包袱：这些细节决定成败
过度设计比不用更糟。BEM本身不提速，但规范执行松散会让团队花更多时间猜类名含义。
性能影响几乎为零，但编译后CSS体积会略增（多了下划线和短横线），不过gzip后可忽略。
- 块名（Block）必须对应独立可复用的UI单元，
.page-header是合理块名，.main-content不是——它缺乏复用性且语义模糊 - 禁止用BEM模拟嵌套关系，例如不要因为DOM里有
<div class="card"><div class="card__body"> <p class="card__body-text"> 就定义 <code>card__body-text，应简化为card__text - 团队第一次对齐命名词典比写代码还重要：明确
card和card-item是否算两个Block，input和form-input哪个才是标准名
真正卡住进度的往往不是语法，而是“这个按钮到底算 button 还是 cta-button”，这类边界问题得靠文档+示例图解决，光靠规范文本没用。
