不能直接在小程序中使用Bootstrap框架，因其CSS依赖的:root变量、媒体查询、伪类选择器等不被支持，JS组件又强依赖document、querySelector等浏览器API，而小程序运行于封闭渲染引擎，无DOM环境，故必然报错或失效。
不能直接在小程序中使用 Bootstrap 框架，哪怕只是引入 bootstrap.min.css 或调用 bootstrap.bundle.js，都会触发构建警告或运行时错误——这不是配置问题，而是底层能力缺失。
为什么小程序里 bootstrap 的 CSS 会失效
小程序的样式系统不支持 Bootstrap 依赖的关键特性：
-
:root变量声明被完全忽略，所有var(--bs-primary)类型的颜色/间距定义无效 - 媒体查询（如
@media (min-width: 768px)）在 WXML 渲染层不解析，.d-md-flex这类断点类名毫无作用 - 伪类选择器（
.btn:focus、.form-control:disabled）在小程序无对应状态机制，不会触发样式切换 -
@import外部 CSS 规则被禁止，无法按需加载bootstrap/scss/mixins等模块
手动提取部分工具类（比如只拷贝 .text-center、.p-2 的声明）可行，但必须逐条剥离变量、嵌套、媒体查询，且无法保证语义一致——.col-6 在小程序里既不响应栅格，也不参与 flex 布局计算。
为什么 bootstrap 的 JS 组件在小程序里必然报错
所有 Bootstrap 5 的 JS 插件（Modal、Dropdown、Toast）都强依赖浏览器 DOM API：
-
document.querySelector和Element.closest在小程序中不存在，document对象根本未暴露 - 事件委托基于原生
click、focusin，而小程序事件系统是 WXMLbindtap/bindfocus，不兼容冒泡路径 -
getComputedStyle、offsetHeight等测量方法在自研渲染引擎中不可用，导致Dropdown.show()直接抛出Cannot read property 'getBoundingClientRect' of null
试图用 Component 构造器封装一个“类 Bootstrap Modal”，本质是重写，不是适配——你写的已经是小程序原生组件，和 Bootstrap 无关。
跨端开发中用 Bootstrap 的真实代价
所谓“一套代码多端运行”，在 Bootstrap + 小程序组合下，实际是三套实现：
- H5 端：直接跑
bootstrap@5.3官方包，享受完整功能 - 小程序端：要么放弃 Bootstrap 语义，改用
nut-button、weui-button等原生组件；要么自己实现一套bs-button，但 class 名、props、生命周期全部重新设计 - uni-app / Taro 环境：虽然能编译出小程序代码，但运行时仍依赖 kbone 或类似适配层模拟 DOM，体积增加 300KB+，首屏延迟明显，且部分交互（如 Tooltip 悬停）无法映射
更隐蔽的问题是调试成本：H5 上好使的 data-bs-toggle="modal" 到小程序里变成静默失败，没有报错，只有白屏或无响应——你得先判断是样式没生效，还是 JS 根本没执行，还是事件没绑定上。
真正可落地的替代路径
如果团队已熟悉 Bootstrap 语义，又必须覆盖小程序，优先走组件库平移而非框架复用：
- 用
@nutui/nutui-miniprogram：提供nut-button、nut-grid，类名前缀统一为nut-，避免和现有 H5 的btn冲突，且支持 Taro/uni-app 编译 - 用
weui-wxss（微信官方）：纯 CSS 方案，无 JS，轻量（weui-btn 和weui-cell可直接替换部分 Bootstrap 布局需求 - 若坚持“类 Bootstrap”开发体验，建议在项目初期就用
UnoCSS+presets-bootstrap自建原子化工具类体系，生成的 class 名（如flex、text-center）可同时用于 H5 和小程序 WXSS，无需维护两套样式逻辑
最常被忽略的一点：小程序里没有“全局样式作用域”，所有 .btn 类都会污染整个页面。Bootstrap 的 class 命名假设了 HTML 全局环境，而小程序每个 WXML 文件默认隔离样式——这意味着，你抄来的 Bootstrap 工具类，可能在 A 页面生效，在 B 页面失效，原因只是 styleIsolation 配置不同。
