滚动穿透是指绝对定位弹窗不阻断底层页面滚动的现象，因CSS定位不改变滚动流且body overflow:hidden在移动端常失效；可靠解法是JS拦截touchmove事件并preventDefault，需设passive:false、精准过滤可滚动区域。
滚动穿透是什么，为什么绝对定位弹窗会触发它
绝对定位的弹窗（比如 position: absolute 或 position: fixed）本身不接管滚动，页面主体仍可滚动——用户手指/鼠标滚轮一动，底下的内容就跟着滑，看起来像“穿”过了弹窗。这不是 CSS 能单独解决的 bug，而是浏览器默认滚动行为在层级叠加时的自然表现。
根本原因在于：CSS 定位不改变元素是否参与滚动流，overflow: hidden 加在弹窗上无效，加在 body 上又常被移动端 Safari 忽略或重置。
给 body 加 overflow: hidden 为什么经常失效
- iOS Safari 会忽略
body 的 overflow: hidden，尤其在弹窗激活后快速滚动时；
- 安卓部分 WebView 对
body 滚动锁定支持不一致，且可能影响页面初始位置（比如跳回顶部）；
- 直接改
body 样式容易和现有 JS 滚动库（如 smooth-scroll）冲突；
-
height: 100vh + overflow: hidden 在 Safari 中可能导致视口计算错误，出现空白条或遮挡。
真正可靠的阻断方式：用 JS 锁定 touchmove 事件
body 的 overflow: hidden，尤其在弹窗激活后快速滚动时；body 滚动锁定支持不一致，且可能影响页面初始位置（比如跳回顶部）；body 样式容易和现有 JS 滚动库（如 smooth-scroll）冲突；height: 100vh + overflow: hidden 在 Safari 中可能导致视口计算错误，出现空白条或遮挡。touchmove 事件
比样式更底层、兼容性更好的做法是拦截原生触摸滚动。关键不是阻止所有事件，而是精准拦截「正在弹窗打开状态下、发生在非可滚动子元素上的 touchmove」。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 弹窗显示时，给
document绑定touchmove监听器，并在回调中调用event.preventDefault()； - 务必加上
{ passive: false }，否则 iOS Safari 会静默忽略preventDefault； - 只在需要时绑定，弹窗关闭后立刻
removeEventListener，避免内存泄漏； - 如果弹窗内有列表等需要滚动的区域（如
.scrollable-area），在事件捕获阶段判断event.target是否在其内部，是则放行。
简短示例：
function lockScroll() {
const handleTouchMove = (e) => {
if (!e.target.closest('.modal-scrollable')) {
e.preventDefault();
}
};
document.addEventListener('touchmove', handleTouchMove, { passive: false });
return () => document.removeEventListener('touchmove', handleTouchMove);
}
要不要用 body { position: fixed } 模拟锁定
这是种“曲线救国”方案：通过把 body 设为 fixed 并设置 top 偏移，让页面视觉上静止。但它有明显副作用：
- 会丢失当前滚动位置，关闭弹窗后需手动
window.scrollTo(0, savedY)恢复，且 iOS 上恢复可能有延迟或抖动； - 若页面有 sticky header 或 CSS
position: sticky元素，body: fixed会让它们失效； - 和某些动画库（如
framer-motion）的布局测量逻辑冲突，导致尺寸错乱； - 不能解决键盘弹出后 viewport 缩小引发的二次滚动穿透（比如 iOS 输入框聚焦后页面上推，再滚就穿了）。
仅当项目已重度依赖该模式、且无 JS 控制权时才考虑，否则优先走 touchmove 阻断。
最麻烦的地方往往不在锁不锁得住，而在「什么时候该解锁」——比如弹窗里嵌了 iframe、唤起系统键盘、或用户切到其他 tab 再切回来。这些边界情况，纯 CSS 做不了，JS 也得留神监听时机。
