Bootstrap 4/5 源码核心结构为 scss/（样式逻辑，含 variables、mixins、组件）和 js/src/（组件JS，依赖统一工具模块）；dist/ 仅为构建产物，非学习入口。
Bootstrap 4/5 的源码目录结构怎么看
直接进 node_modules/bootstrap 或下载的源码包，核心结构其实很清晰：最关键是 scss/ 和 js/src/ 两个目录。前者是样式层的组织逻辑，后者决定组件行为。不要一上来就翻 dist/ 下的压缩文件——那只是构建产物，没法帮你理解设计意图。
常见误区是把 _variables.scss 当成配置入口乱改，结果发现某些组件样式崩了。原因在于：很多组件的 @include 混合宏（比如 button-variant()）内部硬编码依赖了特定变量名或计算逻辑，不是所有变量都支持自由覆盖。
-
scss/bootstrap.scss是总入口，它按顺序加载functions→variables→mixins→ 各组件 SCSS 文件 -
js/src/下每个组件一个文件（如modal.js），但依赖统一的dom/event-handler.js和util/index.js，不是完全独立 - 如果你用的是 Bootstrap 5，注意
js/src/util里大量使用了getComputedStyle()和instanceof判断，对 SSR 环境（如 Next.js）需要条件加载
为什么 Bootstrap 的 CSS 类名设计容易导致样式污染
Bootstrap 的类名策略是「功能导向 + 低特异性」，比如 .btn、.text-center、.d-none。这带来便利，也埋下隐患：一旦项目中存在多个版本的 Bootstrap（比如旧页面引入 v4，新模块用 v5），.d-flex 在 v4 中是 display: flex，v5 中还新增了 display: inline-flex 变体，但类名没变，CSS 规则会叠加冲突。
更隐蔽的问题是 utility-first 类与业务类混用时的维护成本。例如：<div class="card p-3 mb-2 bg-light"> 这种写法在小项目里没问题，但当团队多人协作、组件复用率高时，<code>bg-light 的语义模糊（是背景色？还是强调色？是否响应式？），后续想统一改成深色模式适配，就得全局 grep，而不是改一个主题变量。
- 避免在业务组件中直接写
.col-6这类网格类，应该封装成GridItem组件并控制断点逻辑 - 如果必须定制，优先用 Sass
@use引入模块，而非直接覆盖.btn的 CSS 规则 - Bootstrap 5 移除了 jQuery 依赖，但保留了
data-bs-*属性机制，这些属性名不能随便缩写（比如写成data-bs-toggle="modal"不能简写为data-toggle），否则 JS 插件不触发
Bootstrap 的 JavaScript 插件初始化机制有什么坑
Bootstrap 的 JS 插件（如 Modal、Tooltip）默认靠 data-bs-* 属性自动初始化，看似省事，实则隐藏三个关键限制：
第一，它只监听 DOMContentLoaded 事件做一次扫描，动态插入的 DOM（比如通过 innerHTML 或 Vue/React 渲染）不会被自动接管；第二，插件实例挂载在元素的 bootstrap 属性上（如 element.bootstrapModal），但这个属性名在不同版本不一致（v4 是 bs.modal，v5 改为 bs.modal 的私有 symbol，无法直接访问）；第三，Tooltip 和 Popover 默认依赖 Popper.js，但 Bootstrap 5 把 Popper 打包进了 bootstrap.bundle.js，如果只引 bootstrap.js 就会报 TypeError: Popper is not a constructor。
- 手动初始化时，务必检查插件是否已存在实例：
if (!Modal.getInstance(element)) new Modal(element) - Tooltip 需要显式调用
enable()才能响应 hover，否则只靠 data 属性不会激活 - 在 Webpack/Vite 中，如果用了 tree-shaking，确保
import { Tooltip } from 'bootstrap'后再调用Tooltip.init()，否则插件注册逻辑可能被摇掉
从源码看 Bootstrap 的响应式实现到底依赖什么
Bootstrap 的响应式不是靠 JS 计算屏幕宽度，而是纯 CSS 媒体查询 + 预设断点。所有断点定义集中在 _variables.scss 的 $grid-breakpoints map 里，比如 sm: 576px、md: 768px。关键点在于：这些断点值被同时用于网格系统（.col-md-6）、工具类（.d-md-none）和组件（.navbar-expand-md）——它们共享同一套映射，所以修改断点必须全局同步，不能只改某一部分。
另外，Bootstrap 5 的 container 宽度计算方式变了：不再用固定像素，而是基于 max-width + 100% + margin: 0 auto，且移动端默认为 100%，这使得它天然适配 viewport 缩放，但也会导致在 iOS Safari 横屏时因 viewport 缩放未重置而出现水平滚动条。
- 自定义断点时，别漏掉
$container-max-widths，否则.container在新断点下宽度不会变 -
.d-none类没有媒体查询，它是无条件隐藏；而.d-sm-none才是在sm及以上断点隐藏——注意这个「及」字，容易误判生效范围 - 如果项目需支持 IE11，Bootstrap 5 已不兼容，必须降级到 v4.6 并引入
core-js和web-componentpolyfill，但offcanvas等新组件仍不可用
真正难的不是看懂某个文件，而是理解变量、mixin、utility、组件四层之间的耦合深度——改一个 $font-size-base，可能影响 type-scale() 函数输出、进而改变 h1–h6 的 rem 值、最后让 .lead 的 line-height 计算异常。这种链式依赖，文档很少明说，只能靠读源码里的注释和 import 关系推断。
