Utility类优于内联样式，因其原子化、单职责、可组合，绑定统一变量（如$spacers），改一处即全局同步；支持PurgeCSS剔除未用类，而内联样式无法被识别、无法响应式、无法主题切换，且易引发权重冲突与维护噩梦。
因为 Utility Classes 是原子化、单职责、可组合的样式契约，不是重复声明的样式快照。
多个组件都写 margin-bottom: 1rem，为什么最后变成维护噩梦？
内联样式或手写 class 里反复出现相同数值，本质是把设计约束（比如“卡片下方总留 1rem 空隙”）散落在各处。一旦设计改了，就得全局搜 margin-bottom: 1rem，漏一处就错一处；更糟的是，某处加了 !important 或更高权重选择器，会意外覆盖其他地方。
而 mb-3 这个类名背后绑定的是统一的 $spacers 变量——改一次变量，所有 mb-*、pt-*、mx-* 全部同步更新，无需人工校对。
- 组件内部不再硬编码间距，只负责结构语义（如
.card不带margin-bottom） - 间距交给
mb-3或mb-md-4显式声明，意图清晰且可推导 - PurgeCSS 能准确识别哪些
mb-*实际被用到，没用的类（比如项目根本不用mb-5）会被安全剔除
text-center 和 style="text-align: center" 表面一样，但底层机制完全不同
前者是编译期生成的、带命名空间的 CSS 规则，走的是 Bootstrap 的 $utilities 映射系统；后者是运行时字符串，PurgeCSS 看不见，构建工具无法判断是否冗余，最终全被打包进去。
立即学习“前端免费学习笔记（深入）”；
更重要的是，text-center 在 Sass 层和 text-md-left 共享同一套断点逻辑与主题色配置，而内联样式无法响应式、无法主题切换、无法被变量驱动。
- 内联样式无法参与 Sass 编译流程，改不了断点、换不了主题色
- Utility 类支持
text-primary fw-bold组合，权重可控；内联样式只能靠!important强行覆盖，容易引发级联冲突 - JS 动态拼接
className（如text-${align}）会让 Utility 类失效——这不是 Utility 的问题，而是你越过了它的设计边界
为什么 mt-3 不会和你自己写的 .header { margin-top: 1rem } 冲突？
它会冲突，但冲突方式更可预测、更易调试。Bootstrap 5 的 Utility 类默认带 !important，所以 mt-3 优先级高于普通 class；但如果你自己写的规则也加了 !important，那就要比选择器权重——这时候问题就暴露出来了：你本不该在组件里写死 margin-top，而该用 mt-* 统一管理。
- 冲突不是消失，而是从“不可见的样式覆盖”变成“可见的 class 优先级博弈”
- 真正要避免的不是冲突本身，而是让样式逻辑分散在 HTML、JS、CSS 三处
- 如果发现
mt-3不生效，第一反应不应该是加!important，而是检查父容器是否用了display: contents或 JS 移除了 class
最难的部分不是写 mb-4，而是接受它背后那一整套 Sass 配置——$spacers、$grid-breakpoints、$utilities。这些变量才是真正的样式控制中枢，改它们，才叫“减少重复”，而不是靠多敲几个 class。
