直接写 .button 会破坏样式因CSS全局作用域导致同名类覆盖，BEM通过Block__Element--Modifier命名建立逻辑边界，实现模块化隔离，避免冲突。
为什么直接写 .button 会炸掉别人的样式
因为 CSS 是全局作用域，.button 这种通用名一旦在多个模块/团队/第三方库中重复定义，后加载的规则会覆盖先加载的，且毫无提示。尤其在微前端、SSR 或老项目叠加新组件时，一个 .icon 类可能同时控制着导航图标、弹窗关闭按钮、表格操作列，改一处，三处崩。
常见错误现象：margin 突然变大、display 被强制改成 inline-block、字体颜色莫名继承自某个远古 body 规则——查开发者工具发现是另一份 CSS 文件里的同名类在作祟。
- 别依赖“我们团队都守规矩”：npm 包自带样式、UI 库局部引入、甚至
create-react-app默认注入的index.css都可能埋雷 - 避免用语义化过强但泛滥的命名，比如
.header、.list、.content - 即使加了
!important，也只是把冲突延迟到更难调试的阶段
BEM 命名不是加前缀，而是建隔离墙
BEM（Block__Element--Modifier）本质是靠命名约定制造逻辑边界，让类名自带上下文。关键不在“写得长”，而在“能反向定位来源”。比如 .user-card__avatar--large 一眼可知它属于 user-card 模块，是头像元素，且处于大尺寸状态——这个信息量本身就在阻止误复用。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- Block 名必须具体：用
.search-bar，不用.bar；用.product-grid，不用.grid - Element 用双下划线
__，Modifier 用双短横--，这是硬约定，别写成.searchBar_avatar或.search-bar-large - 禁止跨 Block 写组合选择器：
.user-card .button是反模式，应写成.user-card__action-button - Modifier 不要单独使用：
.button--primary必须和.button同时存在，否则无法保证基础样式兜底
和 CSS Modules / scoped CSS 不是替代关系
BEM 解决的是命名空间污染，CSS Modules 解决的是作用域隔离，二者目标不同。BEM 在全局 CSS 中依然有效；而 CSS Modules 生成的哈希类名（如 Button_button__abc123）其实暗合 BEM 思路——只是自动化了 Block 名绑定。
容易踩的坑：
- 在 Vue 的
<style scoped></style>里仍写.button：scoped 只防父组件穿透，不防子组件或第三方库的同名类 - 用 PostCSS 插件自动转 BEM，结果把
.btn强行变成.my-app__btn：破坏可读性，且和设计系统文档对不上 - 以为用了 BEM 就不用考虑 CSS 优先级：
.card__title--highlight如果比.legacy-header h1优先级低，照样被干掉
从哪开始改最省力又见效
别重写全站，先卡住新增代码入口。新组件、新页面、重构模块，一律按 BEM 写；老代码只在动到样式时顺手升级对应区块。
示例：原有一段脆弱代码
.modal {
z-index: 1000;
}
.close {
float: right;
}
升级后：
.dialog-modal {
z-index: 1000;
}
.dialog-modal__close {
float: right;
}
.dialog-modal__close--hover {
opacity: 0.8;
}
注意：.dialog-modal 是 Block，.dialog-modal__close 是 Element，--hover 是 Modifier——三者缺一不可，少一个就失去 BEM 的防御能力。
真正难的不是写对语法，而是团队对 Block 边界的共识。比如“搜索框+结果列表”算一个 Block 还是两个？这得靠设计系统文档定死，而不是靠开发临场发挥。
