bootstrap 5 默认移动端优先可行但不总推荐，因其基于flex+媒体查询实现响应式，但全量引入、嵌套过深、gap兼容性及表单验证限制易引发h5性能与体验问题。
Bootstrap 5 默认就是为移动端优先设计的，做 H5 页面完全可行，但“可行”不等于“推荐”——关键看项目规模、交互复杂度和性能敏感度。
为什么 Bootstrap 5 的移动端布局默认就“能用”
它底层用的是 display: flex + 媒体查询，col-sm-12 这类断点类在小屏下自动生效，container-fluid 也能撑满视口宽度。不需要额外 hack 就能实现基础响应式结构。
-
row和col在移动端默认是单列堆叠（只要没加flex-row或写死width） -
btn类自带touch-action: manipulation，点击反馈延迟低，适合手指操作 -
form-control在 iOS Safari 中会自动放大字体避免缩放失焦（前提是没禁用user-scalable） - 所有组件（如
dropdown、modal）的 JS 实现已移除 jQuery，体积更小、启动更快
但 H5 页面常踩的三个性能/体验坑
不是框架不行，而是默认用法容易触发移动端短板：
- 全量引入
bootstrap.bundle.min.js（约 100KB+ gzipped）会拖慢首屏 JS 解析，尤其低端安卓机；建议只 import 需要的模块，比如仅用Modal就单独引入bootstrap/js/dist/modal.js -
col嵌套过深（如row > col > row > col）会让 Flex 计算变慢，iOS WebView 中可能出现重排抖动；改用row-cols-2或原生display: grid更稳 -
g-3（gap）在 iOS 14.5 以下 Safari 不支持，若用它做列表项间距，小版本用户看到的是塌陷布局；降级方案是手动加margin-bottom并用@supports (gap: 0)包裹
表单验证在 H5 里特别容易失效
Bootstrap 的 is-valid/is-invalid 类本身没问题，但 H5 场景下几个现实约束让它“看起来没反应”：
- iOS Safari 对
input[type="number"]的checkValidity()返回值不可靠，建议统一用type="text"+ 正则校验 -
invalid-feedback元素若被包裹在div或span里，CSS 选择器.is-invalid ~ .invalid-feedback就不匹配；必须是**紧邻兄弟节点** - 提交时用
form.classList.add('was-validated')是最省事的方式，但要注意：如果表单里混用了自定义校验（如用户名唯一性），得手动调input.setCustomValidity('')清空状态，否则后续输入永远报错
真正卡住的往往不是“能不能做”，而是要不要为一个轻量 H5 页面背 container、row、col 这套语义弱又嵌套深的抽象层——当页面只有 3 个按钮 + 1 张图时，手写几行 flex + 媒体查询，反而更快、更可控、更容易压进 50KB 总资源包里。
