Bootstrap类名越用越“胖”因其功能导向的叠加组合（如btn btn-primary）导致重排增多、特异性升高、维护困难；BEM则通过块-元素-修饰符结构（如.search-form__button--primary）提升可维护性与复用性。
Bootstrap类名为什么越用越“胖”
因为它的类名是功能导向的叠加式组合，不是结构导向的模块封装。btn btn-primary btn-lg rounded-pill shadow-sm 这种写法本质是把多个独立样式单元拼在一起，每个类都可能触发一次重排或增加 specificity 压力。它不关心“这个按钮属于哪个业务模块”，只回答“你现在要什么视觉效果”。
常见错误现象：btn btn-outline-danger p-2 ms-3 中 p-2 和 ms-3 作用于同一元素，但 padding 和 margin 的语义混在一起，后期想统一调整所有按钮内边距时，得全局搜 p-2，而不是定位到 .btn 的样式定义处。
使用场景适合快速原型、后台系统、对可维护性要求不高的内部工具。一旦组件需要复用、状态多、嵌套深（比如带图标+加载态+禁用态的按钮），类名就迅速失控。
BEM类名为什么看起来“啰嗦”但更可控
因为它强制把“谁”“是什么”“现在什么样”三件事拆开表达：.search-form__button--primary 明确表示：这是 search-form 块里的一个按钮元素，当前处于 primary 修饰状态。
容易踩的坑：
- 手写 BEM 类名时漏掉双下划线或双连字符，变成
.search-form_button-primary，语义断裂，VS Code 插件无法补全 - 在 JS 中动态拼接类名，比如
classList.add(`search-form__button--${status}`)，status 取值未校验，导致生成search-form__button--undefined - 误用嵌套元素，写出
.card__header__title—— BEM 规定元素不能嵌套，应改为.card__title或拆出新 block
性能影响小但开发体验差异大：BEM 类名长，但浏览器匹配快（单一 class 匹配）；Bootstrap 类名短，但多 class 组合后 CSS 规则优先级计算变复杂，尤其当自定义样式用 .btn.my-custom-style 覆盖时，容易被 .btn.btn-lg 反向压制。
怎么判断该用 Bootstrap 还是 BEM 风格
看项目里“样式复用”和“逻辑耦合”的边界在哪：
- 如果按钮、卡片、表单控件基本是“一次性”的，且 UI 变动少，Bootstrap 工具类能省掉 80% 的样式文件维护成本
- 如果同一个“订单状态标签”要出现在列表页、详情页、弹窗里，且不同位置有细微样式差异（颜色、圆角、间距），BEM 的
.order-status--shipped+.order-status--cancelled更易隔离和复用 - 如果你用的是 Blazor、React 或 Vue，并配合 Sass/SCSS，BEM 天然适配组件作用域；而 Bootstrap 在这些环境里反而常要额外加
!important或用 CSS Modules 封装，才能避免样式泄漏
参数差异其实不在语法，而在心智模型：Bootstrap 类名是“我要什么效果”，BEM 是“我是什么东西，现在什么状态”。前者快，后者稳。
混合使用的现实约束
现实中没人纯用某一种。但混用必须守住一条线：**块级容器不混名，子元素不跨体系**。
可以接受：
不可接受： —— 把两个体系的类名塞进同一个元素，既破坏 BEM 的 block 独立性，又让 btn 的通用样式污染了业务语义
最容易被忽略的是构建时的副作用：BEM 配合 Sass 的 @include 和 & 嵌套能自动产出正确类名，但 Bootstrap 工具类是静态字符串。一旦你开始用 JS 动态增删 mb-3 或 text-truncate，就等于把样式逻辑从 CSS 搬到了 JS，调试链路变长，CSS 压缩工具也无法安全剔除未用类。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
