BEM在企业项目中失败主因是Block未对齐业务模块、Modifier混淆视觉与状态、Element命名错位；Block须为可交付业务模块（如order-summary），Element仅用业务名词（如product-card__title），Modifier仅限产品定义的稳定状态（如--discounted）。
直接套用 BEM 官方示例（block__element--modifier）在企业项目里大概率失败——不是语法写错，而是 Block 没对齐业务模块、Modifier 混淆了视觉和状态、Element 名称被设计师和前端反复翻译错位。
Block 必须对应可交付的业务模块，不能是 layout 或 container
常见错误是把 .section、.wrapper、.grid 当作 Block。它们没有语义职责，无法被产品文档引用，也不能被组件库索引。一旦 UI 改版，这些类名会散落在几十个文件里，改无可改。
- 正确做法：Block 名 = 业务术语 + 角色，如
order-summary、product-filter、notification-banner - 验证标准：这个 Block 能否独立出现在 PRD 文档中？能否被测试同学在用例里直接点名？
- 禁止出现
homepage-card这类带页面上下文的命名——它破坏复用性，也掩盖了真实职责
Element 名称只用业务名词，不回溯父级语义
product-card__title 合规，product-card__card-title 冗余。BEM 的 Element 不是“描述结构”，而是“表达角色”：只要能说清“这是什么”，就不需要重复 Block 名。
- Element 必须依附 Block 存在，不能跨 Block 复用；若高频复用（如
avatar、badge），它本身就应该升格为 Block - 禁用位置/样式描述：
product-card__left❌ → 改用product-card__avatar或product-card__content - SCSS 中只允许单层嵌套：
&__title✅，&__content { &__icon { } }❌（会编译出后代选择器，破坏封装）
Modifier 只枚举稳定、可预测的业务状态
button--primary 合规，button--red 或 button--loading 是典型陷阱。--red 换主题时要全局搜索替换；--loading 把 JS 状态逻辑硬编码进 CSS，后续加骨架屏或延迟加载就卡住。
- Modifier 值必须来自产品定义的状态池，比如订单状态：
order-summary__total-price--discounted✅，order-summary__total-price--highlighted❌（“高亮”是临时设计需求，非业务事实） - 禁止修饰符叠加：
button--primary--large❌ → 应写作button button--primary button--large - Modifier 必须与主体共存：
button--primary单独使用无效，必须搭配button
让规范真正落地的关键动作
光有命名规则没用。企业项目里最常崩坏的环节，是设计稿到代码的翻译断层、SCSS 编译后选择器失控、以及第三方样式污染。
- 要求 UI 设计师在 Figma 图层名中强制使用 BEM 格式，例如：
product-card__price--on-sale，前端切图时直接读取生成类名 - 在构建流程中接入
eslint-plugin-css-modules，校验 JSX 中 className 是否匹配当前模块声明的 Block 前缀（如Button.module.scss只允许button开头的类） - 所有第三方组件必须包一层 wrapper Block，例如
ant-table-wrapper__table，禁止直接覆盖.ant-table类
最难的不是写对第一个 user-card__avatar，而是确保第 300 个 Block 仍能被新成员一眼看懂职责、被搜索工具准确定位、被主题系统无损接管——这靠的不是模板，而是每次提交前多问一句：“这个类名，产品文档里怎么叫它？”
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
