<p>Bootstrap 4 移动端异常主因是 viewport meta 缺失、navbar-expand-* 类漏写、modal-open 被覆盖及 table-responsive 断点与样式冲突，需严格校验 HTML 结构、CSS 加载顺序和真机渲染状态。</p>
Bootstrap 4 在移动端显示异常，不是框架“不兼容”，而是它对 viewport、断点触发、CSS 层级和渲染行为的依赖，在真实移动设备上被悄悄绕过了——漏一个 meta，少一个类，加一行错位 CSS，就足以让栅格崩、菜单藏、模态框滚穿底。
viewport meta 缺失或写错，所有响应式逻辑直接失效
这是最隐蔽也最致命的问题。没有正确的 <meta name="viewport">，Bootstrap 的 @media (max-width: 768px) 根本不会匹配，.navbar-expand-md 就像没写一样，.col-sm-6 也会按桌面宽度计算。
- 必须写全：
<meta name="viewport" content="width=device-width, initial-scale=1.0"> - 删掉
maximum-scale=1、user-scalable=no—— 它们在 iOS 16+ 已被忽略，还可能强制降级到兼容模式，导致dvh和visualViewport失效 - 真机上
window.innerWidth返回980？基本就是 viewport 缺失，或写成了width=375这类固定值
navbar-expand-* 类漏写或断点不匹配，汉堡菜单根本不出现在 DOM 中
.navbar-expand-lg 不是“锦上添花”，它是折叠菜单的开关。漏写，.navbar-toggler 元素压根不会被渲染；写错（比如 navbar-expand 拼错或没配断点），JS 无法识别，点击按钮静默失败。
- 用 DevTools 查小屏下
.navbar-collapse的display值：如果是block而非none，说明媒体查询没生效 - 检查是否自定义了 Sass 变量（如
$grid-breakpoints）但没重编译 CSS —— HTML 里写的md仍按原始 768px 判断 - 绝对不要在自定义 CSS 里对
#navbarSupportedContent硬写display: block，这会锁死 JS 的.show切换逻辑
modal-open 类被覆盖，页面滚动穿透且关闭后卡死
Bootstrap 4 靠 JS 给 body 加 modal-open 类，再靠 body.modal-open { overflow: hidden; } 锁滚动。这个规则极其脆弱：被更高优先级样式覆盖、加载顺序错、SCSS @extend 干扰，都会让它失效。
立即学习“前端免费学习笔记（深入）”；
- 别写
body { overflow: hidden !important; }—— 关闭后 JS 无法恢复overflow，页面永久锁死 - 确保自定义 CSS 文件加载在 Bootstrap 4 CSS 之后，并在末尾加兜底：
body.modal-open { overflow: hidden !important; } - 检查开发者工具中
body是否真有modal-open类 —— 如果没有，说明 JS 未触发（比如用了data-backdrop="static"却没配对调用）
table-responsive 在桌面端不生效，且移动端滚动卡顿
.table-responsive 在 Bootstrap 4 中只在 max-width: 576px（xs 断点）下启用 overflow-x: auto，桌面端完全无样式。很多人误以为它“该滚不滚”，其实是内容自己先折行了，或者父容器把它截断了。
- 必须配合
text-nowrap或white-space: nowrap，否则文字一换行，表格宽度就塌缩，不触发溢出 - 父容器不能有
overflow: hidden、display: flex（未设flex-shrink: 0）或display: grid—— 这些都会静默禁用滚动 - 移动端卡顿？加
-webkit-overflow-scrolling: touch到.table-responsive上，iOS Safari 必须靠它才能顺滑拖动
真正难处理的从来不是“怎么写”，而是“谁在覆盖你写的”——移动端渲染差异大、CSS 优先级链长、JS 状态易被干扰，建议每次改完都用真机 + 开发者工具的 Elements 面板逐层看 class 存在与否、样式是否被划掉、computed overflow 是否生效。细节堆叠起来，就是显示异常的全部原因。
