模块化引入按需加载组件代码，全量引入则强制载入所有功能。bootstrap 通过独立 scss 文件和 es 模块实现物理与运行时分离，避免未用代码影响首屏性能（如 lcp）。
Bootstrap 的模块化组件开发思想，不是把所有 CSS 和 JS 打包成一个“大文件”硬塞进项目，而是把每个功能单元（比如 button、modal、dropdown）拆成独立可选的模块，按需加载、按需编译、按需定制。
模块化 ≠ 组件化，但 Bootstrap 同时支持两者
模块化指物理层面的代码组织：Bootstrap 的源码中，scss/ 下每个组件有单独的 _button.scss、_modal.scss 文件；js/src/ 下对应 button.js、modal.js。你可以只 @import "bootstrap/scss/button"，不碰 carousel 一行代码。
组件化则强调运行时行为封装：每个组件拥有自己的初始化逻辑、事件绑定、状态管理（如 Modal 的 show()/hide() 方法），且默认不污染全局作用域。
- 用 Sass 编译时，删掉
@import "bootstrap/scss/dropdown"，最终 CSS 就真不包含下拉菜单样式 - 用 ES 模块引入时，
import { Modal } from 'bootstrap'不会自动带入Tooltip的 JS 代码 - CDN 全量引入（
bootstrap.bundle.min.js）是便利妥协，不是模块化本意
为什么必须区分 “模块化引入” 和 “全量引入”
全量引入 bootstrap.bundle.min.js 看似省事，但实际会把未使用的组件 JS 逻辑（比如你根本不用 offcanvas）也载入内存，增加首屏体积和解析时间。2026 年主流项目已普遍要求 LCP
- Webpack/Vite 项目中，直接
import { Alert } from 'bootstrap'可触发 tree-shaking - Sass 用户若仍用
bootstrap.min.css，等于放弃模块化带来的定制自由度 - Bootstrap 官方 npm 包的
js/dist/目录下，每个组件都有独立 UMD 文件（如modal.js），但需手动处理依赖（Popper、dom-helpers）
容易被忽略的模块间隐式依赖
模块化不等于完全解耦。例如：dropdown 组件在 JS 层依赖 Popper.js 做定位，tooltip 和 popover 同样如此；modal 依赖 focus-trap 行为。这些不会报错，但缺失时功能会静默失效。
- ESM 引入
Dropdown时，必须确保@popperjs/core已安装且版本匹配（Bootstrap 5.3+ 要求 v2.11+） - Sass 中启用
dropdown样式，不需要额外引入 Popper，但 JS 行为层必须补上 -
bootstrap/scss/functions和variables是所有组件的公共基础模块，删掉会导致编译失败
真正落地模块化，关键不在“能不能拆”，而在构建流程是否识别模块边界、运行时是否按需激活——否则只是把“大包袱”换成了“多小包袱”。
