BEM 是构建时契约而非命名习惯，必须通过工具链焊死：启用 stylelint-selector-bem-pattern 强制校验，CI 拦截非 BEM 选择器，目录结构与组件一一对应，修饰符仅描述稳定状态且不可叠加。
不是“应该推行”，而是不推就崩——类名冲突、样式覆盖、调试耗时这三件事会在第3个迭代后变成每日必修课，且无法靠人盯防解决。
为什么 .btn 这种类名在协作中必然失效
多人并行开发时，.btn 被登录页、弹窗、表单各自定义是常态。一个加了 margin-right: 8px，另一个加了 display: inline-flex，没人能保证它们该一致还是该不同。审查元素里看到两个 .btn，根本分不清哪个生效、谁改的、影响范围多大。
-
.auth-form__submit和.settings-form__submit天然隔离，改一个不影响另一个 - 块名必须带业务语义前缀：
user-card✅，card❌（否则和product-card冲突） - 禁止用
global、base、layout这类泛义词当 block 名，它们第3轮迭代就成黑洞
为什么 BEM 不是命名习惯，而是构建时契约
BEM 的约束力不来自文档，而来自工具链是否焊死。手滑一次 .header .logo 或漏写基础块样式，整个模块的样式契约就松动。
- 必须启用
stylelint-selector-bem-pattern，配置{ "styleType": "bem" }，设为error级别 - CI 中跑
npx stylelint "**/*.{css,scss}"，拦截button--primary--large、.card .title、avatar--xs - 构建后执行
grep -r "\.[a-z]\+ \.[a-z]" dist/，揪出所有残留空格选择器 - 目录结构必须对齐：
/components/user-card/user-card.css里出现.product-grid__item就该立刻 fail
为什么修饰符滥用比没写 BEM 更危险
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--large--disabled是反模式；应拆成button--primary button--large button--disabled -
@media块内只允许一个 BEM 类选择器，禁止写.product-grid .product-card
真正难的不是写出 block__element--modifier，而是让团队在加一个 tooltip 时，本能地新建 /components/tooltip/，而不是往 modal.css 里塞 .modal__tooltip——这需要目录约束、CI 拦截、以及最初几个模块的示范性实现。一旦松动，BEM 就退化成“带下划线的普通 CSS”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
