这事儿得怪iOS WebKit那个老毛病。它有一个独特的处理逻辑：如果body没有明确设置height: 100vh或者overscroll-beha vior，同时内容高度又超过了一屏，那么overflow: hidden就形同虚设了。更要命的是，Safari会主动把touchmove事件“穿透”到那些还能滚动的祖先元素（比如body）上去，即使上面已经被fixed元素盖得严严实实。

• 稳妥起见，建议body同时设置overflow: hidden和position: relative（后者能预防某些安卓机型上的备用方案失效）
• 只靠CSS解决？在iOS上是不够稳妥的，通常还需要配合Ja vaScript，用touchmove事件来阻止默认行为
• 别只盯着html或者body中的一个，这两个元素常常需要协同作战，才能有效控制滚动

用 overscroll-beha vior 简单封住穿透（现代方案）

如果要找一个目前最优雅、最干净的解决方案，那肯定是overscroll-beha vior。它的作用很直接：告诉浏览器，“这个容器滚到边界了，别再把它传递给你的父级了”。听起来很理想，对吧？不过得注意，它不支持iOS 15以下版本以及一些旧版的Android WebView。

• 对于弹窗遮罩层内部需要滚动的区域（例如.modal-content），加上overscroll-beha vior: contain
• 对于body元素本身，则可以加上overscroll-beha vior: none（实际上，这比单独使用overflow: hidden要可靠得多）
• 一个关键的细节：这个属性只管“滚动溢出”的行为，它可不负责决定容器本身能不能滚——你得确保容器内容确实是可滚的，这个属性才会生效

body {
  overscroll-beha vior: none;
}
.modal-scrollable {
  overscroll-beha vior: contain;
  overflow-y: auto;
  height: 80vh;
}

Ja vaScript 补漏：监听 touchmove 并 preventDefault

为了覆盖iOS 12到14，以及某些安卓WebView的老旧环境，Ja vaScript的补丁是绕不开的。但这里有个雷区：不能粗暴地阻止所有的touchmove事件，否则你会让你的遮罩层内部那个需要滚动的列表或者内容区完全失灵。

立即学习“前端免费学习笔记（深入）”；

• 正确的做法是：只在遮罩层显示时，才给body绑定touchmove监听器，并且把调用preventDefault()的条件严格限定在“当前触发的目标元素不在允许滚动的容器内”
• 事件处理逻辑里，应该优先检查event.target是否位于我们指定的可滚动容器内部，是则放行，否则阻止
• 任务完成后，千万别忘了在遮罩层关闭后解除事件监听，这不仅是为了避免内存泄漏，也是为了不影响页面的后续交互

一个清晰的实现逻辑示例如下：

function lockBodyScroll() {
  const handleTouchMove = (e) => {
    if (e.target !== document.body && !e.target.closest('.scrollable')) {
      e.preventDefault();
    }
  };
  document.body.addEventListener('touchmove', handleTouchMove, { passive: false });
}

说到底，处理滚动穿透这件事，复杂之处就在于它并不是简单地“打开一个开关”。整个方案需要在fixed定位容器、滚动上下文叠加层级以及事件捕获传递链这三个战场上来回校准。最常见的疏忽是什么？往往是：你确实给body加了overscroll-beha vior: none，却忘了给遮罩层内部的某个子滚动容器（比如一个评论列表）也明确加上overscroll-beha vior: contain，结果滚动行为还是悄无声息地“穿”了出去。这个细节，才是胜负的关键。