Bootstrap类名不等于CSS选择器逻辑，依赖其HTML结构与命名约定；需理解特异性、状态类动态注入、utility类的!important机制及断点依赖容器上下文。
Bootstrap类名不是CSS选择器的替代品
直接用 .btn、.card-title 这类类名写样式，本质是依赖框架的HTML结构和命名约定。它不等于你掌握了CSS选择器逻辑，反而容易掩盖对层级、组合、伪类等真实机制的理解断层。
常见错误现象：div .btn 想覆盖按钮样式却失效；给 .nav-link 加 :hover 但没生效——其实是Bootstrap用了 .nav-link:hover 更高优先级规则，或启用了CSS-in-JS注入方式。
- Bootstrap的CSS是预编译生成的，大量使用嵌套（如
.dropdown:hover .dropdown-menu），手动复现需严格匹配其HTML上下文 - 自定义样式时，优先用更具体的类（如
.my-btn-primary）而非强行提高选择器权重（如body .btn.btn-primary） - 若用SCSS源码定制，应通过变量（
$primary）和mixin（button-variant()）介入，而非在外部CSS里暴力覆盖
data-* 属性和JS钩子会干扰纯CSS选择器行为
Bootstrap组件（如Modal、Tooltip）依赖 data-bs-toggle、data-bs-target 等属性控制状态，而这些属性本身不带样式，但JS会在运行时动态增删类（如 .show、.fade）。只靠静态CSS选择器抓不到这些变化后的状态。
使用场景：想让弹窗内容区在打开时加阴影，但写 .modal.show .modal-content 发现不生效——因为 .show 类可能被加在父容器 .modal 上，而 .modal-content 并未直接受控。
立即学习“前端免费学习笔记（深入）”；
- 检查实际DOM：打开浏览器开发者工具，看JS到底把类加在哪个节点上
- 避免用
[data-bs-toggle="modal"]直接写样式，这类属性无视觉意义，且可能被JS移除或重命名 - 需要响应状态变化时，优先监听Bootstrap的事件（如
shown.bs.modal），再动态加自定义类
utility类（如 mt-3、fw-bold）会覆盖你的自定义规则
Utility类是Bootstrap最易误用的部分。它们用 !important 声明（部分版本）、高特异性（如 .mt-3 编译为 margin-top: 1rem !important），导致你在自己的CSS里写的 margin-top: 0 完全无效。
性能影响：每个utility类都对应一条独立CSS规则，滥用会导致CSS体积膨胀，尤其当项目只需其中几个间距值时。
- 禁用不需要的utilities：在SCSS中通过
$utilitiesmap剔除，比如删掉所有mb-类 - 不要混用：避免同时写
class="mt-2 my-custom-margin"，除非my-custom-margin明确用!important或更高特异性 - 用CSS自定义属性替代：如定义
--my-spacing: 0.5rem，再用margin-top: var(--my-spacing)，比堆砌mt-1mt-2更可控
响应式断点（sm/md）必须和容器宽度严格对齐
Bootstrap的 d-none d-md-block 这类类名生效，前提是父容器没有意外的 max-width 或 transform，否则媒体查询计算的视口宽度会失真。尤其在iframe嵌入、缩放页面或使用CSS zoom 时，断点常“卡住”不动。
兼容性影响：旧版IE不支持 min-width 媒体查询，而Bootstrap 5已放弃IE支持，但若项目需兼容Edge Legacy，col-md-6 可能退化为单列。
- 验证断点是否触发：在DevTools里临时修改
window.innerWidth，观察类是否切换，而不是只看屏幕尺寸 - 避免在非Bootstrap容器上强行套用栅格：如把
col-6放进position: absolute元素里，它会脱离flex布局上下文，失去宽度计算依据 - 自定义断点时，同步更新
$grid-breakpoints和$container-max-widths，否则container-md的最大宽度和col-md-6的换行阈值会错位
真正难的不是写对一个 .btn-primary，而是当它和自定义动画、第三方图表库、微前端子应用混在一起时，哪个 display 值最终胜出——这时候选中器的特异性、层叠顺序、渲染时机，全得手拆DOM看。
