BEM 是通过命名规则将样式意图编码进类名的协作方案，而非美化 CSS 的技巧；其双下划线和双破折号语法支持工具链识别、避免命名冲突、保障重构安全，并需配合函数化生成与渐进式落地。
直接说结论：BEM 不是“让 CSS 更好看”的技巧，而是用命名规则把样式意图编码进类名里——.header__logo--dark 这种写法，能让三个人同时改代码时互不干扰，也不需要开会解释“这个类到底管谁”。
为什么 .btn 和 .button 会在协作中引发冲突
多人并行开发时，泛义类名天然缺乏上下文。一个叫 .btn 的样式可能被登录页、弹窗、表单组件各自复用，但没人能保证它在所有地方都该有 margin-right: 8px。一旦某人加了 .btn--primary，另一个人却在 JS 里写 el.classList.add('btn')，结果就是按钮在某个模块突然变宽——而审查元素只看到两个 .btn，根本分不清哪个生效。
使用 BEM 后，每个组件自带命名空间：
-
.auth-form__submit只属于登录表单，不会影响.settings-form__submit -
.card__title和.modal__title是完全隔离的，哪怕样式规则一模一样 - 修饰符如
--disabled或--loading描述状态，不是尺寸或颜色，避免后续响应式或主题切换时要全局搜200px改成100vw
__ 和 -- 不是风格偏好，是工具链识别边界
PostCSS 插件、VS Code BEM 自动补全、甚至某些构建时 CSS Scope 提取工具（如 css-modules 的 BEM 模式），都依赖双下划线和双破折号做语法解析。写成 .menu_item 或 .button-disabled，工具就无法识别这是元素还是修饰符，也就没法自动校验、生成类型定义或做重构提示。
常见错误现象：
- 用单下划线：
.user_profile→ 工具当普通单词，不认为是user块下的profile元素 - 修饰符混用单位：
.input--width-200px→ 换成 rem 或响应式后必须全量替换，且语义丢失（到底是“宽”还是“紧凑态”？） - 块名带样式描述：
.red-card→ 后续换主题时得重命名整个块，而不是只改--theme-dark
如何在 Vue/React 项目里不手拼字符串
硬编码 class="card__body" 或 JS 里写 el.classList.add('card__body') 是最大隐患：重构块名时漏改一处，样式就断掉，且无报错。
实操建议：
- Vue 3
setup中用computed封装 BEM 工厂函数，例如：const bem = (block) => ({ el: (element) => `${block}__${element}`, mod: (mod) => `${block}--${mod}` })然后:class="bem('card').el('body')" - React 用
clsx配合常量对象：const card = { block: 'card', body: 'card__body', title: 'card__title' }再className={clsx(card.body, isExpanded && card.block + '--expanded')} - 禁止在 JS 里直接写带
__或--的字符串；所有类名必须通过常量或函数生成
老项目接入 BEM 最容易被忽略的点
不是“要不要用”，而是“从哪开始封口”。全量重命名成本高、风险大，但放任新代码继续用 .list-item，半年后就会出现 .user-list .item 和 .user-list__item 并存——开发者根本不敢删任何一个，因为不知道谁在用。
真正关键的动作只有两个：
- 立刻禁止新增非 BEM 类名：CI 流水线加 PostCSS 插件校验，检测到
.btn类名直接报错 - 只对“被修改的组件”落地 BEM：比如修一个 bug 涉及
.header，那就顺手把它和子元素全部转成.header__logo、.header--sticky，不动的部分先留着
全局工具类（如 .sr-only、.clearfix）和第三方组件库类名（Ant Design 的 .ant-btn）不强制 BEM，但必须明确归档到 base/ 目录并加注释——否则新人会以为“BEM 就是全部重写”，反而放弃推进。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
