直接给.modal-body加overflow-x:auto无效，因.modal-dialog的flex布局会截断其水平滚动上下文；必须用新容器（如.scrollable-nav）脱离flex流，设overflow-x:auto、white-space:nowrap及-webkit-overflow-scrolling:touch，并确保子项不换行、不收缩。
为什么直接给 .modal-body 加 overflow-x: auto 没用
因为 .modal-dialog 默认是 display: flex，它会截断子元素的水平滚动上下文。浏览器根本不会把 .modal-body 当作一个可横向滚动的容器——哪怕你加了 overflow-x: auto，只要父级 flex 容器没“放行”，滚动行为就被压制了。
常见错误现象：.nav 或 .list-group 在手机上依然换行、撑宽、无法拖动，开发者反复检查 CSS 却找不到问题根源。
- 真正要滚动的必须是
.modal-body的**直接子容器**（比如<div class="scrollable-nav">），不是.modal-body本身 - 这个新容器必须脱离
.modal-dialog的 flex 流，常用手段是设display: block或显式flex: none - 别在
.nav上直接设overflow-x—— 它只是 flex 子项，不是滚动容器
怎么写才让导航条在 Modal 里真正可水平滑动
核心是三层结构：外层固定宽度容器 + 中间强制单行布局 + 内部子项不收缩。缺一不可。
- 给新容器（如
<div class="scrollable-nav">）加：overflow-x: auto、white-space: nowrap、-webkit-overflow-scrolling: touch - 对里面的
.nav设：display: flex、flex-wrap: nowrap、gap: 0.5rem - 每个
.nav-item必须设：flex: 0 0 auto或display: inline-block，防止被 flex 均分压缩 - 移动端小屏下建议用媒体查询激活：
@media (max-width: 767px) { .scrollable-nav { overflow-x: auto; } }
iScroll 是不是更稳妥？什么时候该上
当原生 overflow-x 在 iOS Safari 或某些 Android WebView 上反复失效（拖不动、卡顿、无惯性），或者你需要监听拖拽事件、控制回弹边界、禁止垂直滚动时，iScroll 就不是“备选”，而是必要方案。
- 初始化目标必须是那个新容器（如
.scrollable-nav），不是.nav本身 - 必须等 Modal 完全显示后再初始化：
$('#myModal').on('shown.bs.modal', () => { new IScroll('.scrollable-nav', { scrollX: true, scrollY: false }); }); -
scrollX: true和scrollY: false必须显式声明，否则默认只响应垂直手势 - 如果 Modal 是 React/Vue 动态渲染的，别在
mounted或useEffect里立刻初始化，先确保 DOM 已挂载且尺寸已计算完成
移动端 Safari 滚不动？关键就那一行
不是代码写错了，是 WebKit 渲染限制：即使容器宽度超限、overflow-x: auto 也写了，iOS Safari 仍可能卡顿或无惯性。这不是 bug，是底层机制。
-
-webkit-overflow-scrolling: touch必须加在**实际发生滚动的容器上**，也就是那个.scrollable-nav，不是.modal-body或.modal - 这行只对 WebKit 内核生效（Chrome/Safari/Edge），Firefox 不需要也不识别
- 如果用了
overlay-scrollbars或simplebar等第三方滚动库，它们会接管原生滚动，这行就失效了 - 检查是否意外触发了
touch-action: pan-y（常见于地图、轮播组件），临时加touch-action: pan-x可快速验证
.modal-dialog 的 flex 截断，以及是否把 -webkit-overflow-scrolling: touch 放在了真正滚动的那个元素上——这两点最容易被忽略，但恰恰决定成败。 
