小程序弹窗打开后，手指按在灰色遮罩上一划，后面列表还是会动，是哪里没拦住？

结论先行：小程序弹窗打开后背景还能跟着滑动，多数不是遮罩层没盖住，而是遮罩只挡住了点击、没拦住触摸滑动手势，手指一划，滚动就被传给了弹窗下面的页面。2026 年常见做法是：弹窗开启时锁住底层页面滚动，关闭后再把滚动位置还原。判断是否合格很简单——手指按在遮罩上上下划，背景页面不该有位移。

弹窗打开背景还能滑，问题一般出在哪

小程序页面本身就是整页滚动的容器，弹窗通常用 fixed 定位盖在上面。遮罩能接收点击事件，却不一定能接收并阻止滑动事件。当弹窗内容本身不够长、没有自己的滚动区域时，手指在遮罩上滑动，事件会冒泡到页面层，页面就跟着滚。这就是常说的滚动穿透。

它带来的直接后果是：用户本来只想关掉弹窗，结果划走了背景内容；返回后发现列表位置变了，又得重新找。按企业项目交付习惯，弹窗、抽屉、底部选择器这类覆盖层，都要单独核对滑动表现，而不是只看能不能点。

• 遮罩只写了背景色和层级，没有拦截 touchmove 事件；
• 弹窗内容不可滚动，比如只有一个确认按钮，手指落点在遮罩空白处；
• 底层页面很长，一划就是几百像素位移，问题看起来更明显；
• 只在部分机型出现，安卓和 iOS 在触摸手势处理上存在差异。

先分清是滚动穿透，还是弹窗本身写错了

先别急着改代码，用三查法把现象分清楚：查手势落点、查弹窗内容、查底层滚动容器。分清楚之后，改的还是同一处地方，但排查时间通常能从大半天缩到半小时左右，属于经验区间。

1. 查手势落点：手指按在遮罩空白处滑动，看背景动不动；再按在弹窗卡片上滑动，看是不是一样。两者表现不同，说明问题在遮罩这一层。
2. 查弹窗内容：如果弹窗里有长列表、条款文本，它自己需要滚动，那就要判断是弹窗内滚动正常、背景也滚，还是弹窗内根本不滚。
3. 查底层容器：确认页面滚动是在 page 层，还是某个 scroll-view 里。scroll-view 的穿透表现和整页滚动不一样，锁的方式也不同。

合格的判断口径是：弹窗打开期间，背景页面位置固定不变；弹窗关闭后，页面停在打开前的位置，而不是跳回顶部。

几种锁滚动做法，分别适合什么情况

没有一种写法能通吃所有页面。按 2026 年项目交付习惯，常见做法可以归为三类，选择依据是页面结构复杂度和你愿意承担的维护成本。

• 方案 A：遮罩层拦截滑动事件。给遮罩加 catchtouchmove，阻止事件往下传。改动小、上手快，适合弹窗内容不需要滚动、页面结构简单的场景；缺点是弹窗内部有滚动内容时要单独放开，否则弹窗自己也滑不动。
• 方案 B：打开弹窗时锁住页面。弹窗开启时给底层页面加固定定位，记录当前滚动位置，关闭时再还原。适合底层是长列表、需要严格锁住的页面；代价是要处理位置还原，处理不好关闭弹窗会跳到顶部，返工通常 1~2 轮，属于经验区间。
• 方案 C：用覆盖层组件统一处理。部分小程序基础库提供了自带遮罩与滚动锁定的覆盖层组件，具体能力以官方文档为准。适合弹窗类型多、想统一收口的项目；需要注意基础库版本兼容和自定义样式空间。

如果是多个页面、多个弹窗，建议不要一处处手写，而是把它封装成一个统一组件。判断封装是否合格的标准是：新页面接入时只填内容，不需要再关心锁滚动这件事。

从可核对对比看，方案 A 的改动量常见为几行到一两处，方案 B 要多处理位置记录与还原，方案 C 前期封装成本高一些，但后续每新增一个弹窗的接入成本会低很多。按项目经验区间，弹窗数量在三个以内时，A 或 B 往往够用；超过五个且分散在多个页面时，统一封装的长期维护成本通常更低。

适用场景与边界

滚动穿透值得专门处理，但也不是每个弹窗都要上完整方案。判断依据是：弹窗下面有没有可滚动内容、用户会不会在遮罩上滑动。

• 适合处理：底部抽屉、筛选面板、地址选择、日期选择、半屏说明页，以及带长列表的页面上的弹窗。
• 可以简化：只有两三屏内容、弹窗一出现就基本不滑动的短页面；纯提示型弹层，不少平台组件已经自带遮罩和锁定能力。
• 不必上：整页跳转的页面，以及弹窗打开后已经占满全屏、底下没有可滚内容的场景。
• 常见坑：锁了弹窗忘了恢复、多个弹窗叠加时锁被提前解开、弹窗关闭后页面跳回顶部。

交付现场常卡在哪

在项目里常见的情况是：预算和排期都压得比较紧，弹窗只按能弹出来、能关掉来验收，滑动表现没进验收清单；等真机上给客户演示时，手指一划背景就跑，客户当场提出来，开发再回头补，通常要多花 0.5~1 天返工，属于经验区间。做法上，比较稳的方式是在提测前就把弹窗、抽屉、选择器列成一张覆盖层核对清单，逐个在安卓和 iOS 真机上滑一遍再交。这样做的代价是测试时间会增加一些，常见区间是每个覆盖层多花几分钟到十几分钟，但能减少上线后返工。

有些团队会把这项工作交给开发自测，产品只在最后点一遍，结果就是漏掉按钮少、内容短的弹窗。更稳的分工是：开发负责锁滚动和位置还原，测试负责在真机上按遮罩、按内容区各滑一次，两边都确认后再合入。犀跃公司在移动端定制交付里，也会把这类交互细节放进自测项，而不是等甲方发现。

常见问题

弹窗打开后背景还能滑，是遮罩透明度或者颜色设错了吗？

基本不是。遮罩颜色只影响视觉遮盖，拦不住触摸滑动，问题在于滑动事件没被阻止，或底层页面没有被锁住。

iOS 上没问题，安卓上背景能滑，需要分别写两套逻辑吗？

多数不用写两套逻辑，按统一方式锁住底层滚动后，两端表现通常就一致；但仍建议在安卓和 iOS 真机上分别回归一遍。

锁住滚动以后，关闭弹窗页面跳到顶部了，能修吗？

能。常见做法是锁定前记录当前滚动位置，关闭弹窗时还原回去；这一步放在统一组件里处理，别每个页面各写一遍。

弹窗里面的内容很长，自己也要滚，会不会和锁滚动冲突？

会。通常做法是只在遮罩上拦截滑动，弹窗内容区保留自己的滚动能力，两者分开处理；测试时两边都要滑一遍。

每个弹窗都要单独处理一次，工作量会不会很大？

弹窗少时可以逐个处理；超过三五个、页面又多时，封装成统一覆盖层组件更省事，后续维护成本也更低。

如果你的小程序里已经有弹窗、抽屉或底部选择器，建议先在安卓和 iOS 真机上各滑一遍，把会漏滚动的场景列出来，再决定是逐个修还是统一封装；页面很短、弹窗下面没什么可滚内容的项目，可以先不动。拿不准时，按官方文档核对基础库支持情况与组件能力再动手。