bem是百人协作下守住样式边界的最低防线，通过block__element--modifier三段式将归属、层级、状态锁进类名，使冲突从随机覆盖变为结构错误可查。
因为不统一 BEM，类名冲突和样式覆盖就不是“可能出问题”，而是“每天必修课”。它不是让 CSS 更优雅的风格选择，而是百人协作下守住样式边界的最低防线。
类名冲突在多人并行时必然发生
泛义名如 .btn、.header、.card 在不同模块里被重复定义是常态。微前端场景下，子应用各自引入 common.css，.card 覆盖 .card 不报错，但卡片圆角突然变直、文字溢出——你得花 40 分钟定位是哪个 .card 里的 overflow: hidden 被删了。
- Block 名必须带业务语义前缀：
user-profile✅，profile❌（避免和product-profile冲突） - 禁止用
global、base、layout这类泛义词当 block 名，它们注定会在第 3 个迭代时变成命名黑洞 - 所有响应式变更必须绑定到具体 BEM 类：
product-grid--two-column✅，.product-grid .product-card❌（禁止空格选择器）
修饰符滥用会让状态管理变成猜谜游戏
button--width-200px、card--top-16 这类含值修饰符，换设计稿就得批量新增类；user-card--active 和 user-card__avatar--active 混用，没人能说清哪个优先级更高。
- Modifier 只描述稳定状态：
button--primary✅，button--w-200❌ - 元素级修饰符不能脱离块存在：
user-card__avatar--large✅，avatar--large❌ - 多个修饰符应布尔组合：
button--primary button--large button--disabled✅，button--primary--large--disabled❌（CI 阶段必须用stylelint-selector-bem-pattern拦截）
构建工具和目录结构必须与 BEM 对齐
BEM 本身不产生可维护性，它只是把“谁该管什么”刻进类名里。真正卡死项目的，永远是修饰符叠加、状态类混用、CSS 文件引入顺序混乱这三件事——它们不会在 DevTools 里报错，但会让你在凌晨两点还在比对打包后的 dist/main.css 里第 372 行和第 1894 行谁覆盖了谁。
- 每个 block 对应一个一级目录：
/components/product-card/，文件名与 block 名严格一致：product-card.css→.product-card - Scss 中禁止
& a、& > span等无语义嵌套，否则等于绕过 BEM 防线 - 工具链必须校验：
postcss-bem-linter或stylelint的selector-bem-pattern规则要开到error级别
最常被忽略的一点：BEM 要求你为每个视觉单元都明确回答三个问题——“它是不是独立块？”“它属于哪个块？”“它的状态是否可枚举且稳定？”。没想清楚就写类名，后面补救的成本远高于一开始慢半拍。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
