Bootstrap 本身并未采用 BEM 命名规范，直接混用 BEM 类名无法自动获得其样式支持；然而在 Bootstrap 框架基础上，使用 BEM 规范编写自定义辅助 CSS，能够有效隔离业务逻辑、防止样式污染，并显著提升项目的长期可维护性。
Bootstrap 框架默认不遵循 BEM 规范，这是开发者需要明确的事实。因此，如果在项目中直接使用 .user-card__button--primary 这类 BEM 类名，并不会自动继承 Bootstrap 的样式效果。但关键在于：在 Bootstrap 基础上，采用 BEM 规范编写自定义辅助 CSS，能够有效实现业务逻辑隔离、防止样式冲突，并大幅提升代码的长期可维护性，这才是真正的价值所在。
为何不能直接将 Bootstrap 类当作 BEM 块使用
Bootstrap 中的 card、btn 属于通用原子类或语义化组件类，缺乏 Block 上下文信息——它并不表达“这是用户卡片中的按钮”，仅表示“这是一个具备样式的按钮”。对比 与 ，两者在语义表达、复用能力以及代码定位方面存在本质差异。
card-title与product-card__title截然不同：前者容易被其他页面的.sidebar .card-title样式意外覆盖；而后者通过全局搜索product-card__title即可精准定位所有相关样式定义。- 一旦调整父容器结构（例如将
.card替换为），所有依赖.card > .card-title的父子选择器将立即失效；而.product-summary__title只要类名保持不变，样式就能持续生效。 - Bootstrap 中并不存在
btn--loading这类写法——它没有采用双中划线修饰符机制，状态变化依赖叠加类（如btn btn-primary disabled）实现，这会导致选择器优先级不可控，并增加样式重排的风险。
如何在 Bootstrap 项目中安全地引入 BEM 辅助类
核心思路并非替换 Bootstrap，而是利用 BEM 封装业务逻辑层，让 Bootstrap 专注于视觉基础能力。具体实施时，可以按照以下方式组织代码：
- 创建独立的 SCSS 文件（例如
_user-card.scss），无需引入整个 Bootstrap，仅按需导入变量和 mixin：@import "bootstrap/scss/functions"; @import "bootstrap/scss/variables"; - 块名称应具备抽象性并携带业务前缀：
.user-card✅，.homepage-user-card❌（过于具体，复用性差）。 - 元素必须绑定到所属块：
.user-card__avatar✅，.user-card .avatar❌（后者一旦移动结构就会失效，且容易造成样式污染）。 - 修饰符的值必须校验有效性：JS 动态拼接时避免
status为空，否则会生成.user-card__button--这类无效类名，导致样式静默失效。
BEM 辅助类与 Bootstrap 工具类共存时的注意事项
Bootstrap 中的 mt-2、p-3 等工具类是全局且无上下文的，它们与 BEM 类名存在天然冲突——既不能也不应将 mt-2 改写为 user-card__content-mt-2。
- 正确做法：工具类仅适用于原型开发或临时调试，上线前应转换为 BEM 元素的内联声明（例如
.user-card__content { margin-top: 0.5rem; }）。 - 避免在 BEM 元素上堆叠过多工具类：
—— 这种写法会使p-3的语义变得模糊（是 header 的内边距，还是整个卡片的内边距？），后期统一调整内边距时难以精准定位。 - 如果确实需要保留工具类，务必使用命名空间进行隔离，例如
u-mt-2（u-前缀明确标识为工具类），避免与业务 BEM 类名产生混淆。
BEM 辅助 CSS 的真正价值不在于“书写风格是否规范”，而在于“修改时是否敢于操作”：当删除一个组件文件时，所有相关样式应该彻底消失，而不是散落在数十个 .btn、.card-body 规则中，等待某次重构时意外暴露。这需要从第一个 __ 和第一个 -- 开始建立约束，而非等到样式失控后再进行补救。
