2026年了，弹窗的灰色遮罩只盖住卡片那一块，周围页面还能点，是遮罩没铺满吗？

弹窗的灰色遮罩只盖住卡片那一块、周围页面还能点到，通常不是遮罩宽高写小了，而是某层祖先带着 transform、filter、will-change 或 contain，替 fixed 元素重新划了包含块，遮罩就从“相对视口”变成“相对这一层”。2026 年按常见交付习惯，先顺着祖先链确认它到底跟着谁滚，再动样式，比反复调高度和 z-index 省时间。

为什么动画一加，遮罩就只盖住一块

position: fixed 默认按视口定位。但祖先链上只要有一层生成了包含块，fixed 元素就改为相对那一层定位，页面滚动时它跟着祖先一起走。表现出来就是：遮罩只盖住卡片、抽屉只盖住容器、滚到下面就看不见。这属于规范内的行为，不是浏览器出了 bug。

进场动画是最常见的触发源。滑入用的 translateY、弹入用的 scale 都靠 transform 实现，不少动画库还会直接给整块容器挂 transform。更麻烦的是动画播完后属性值往往不是 none，而是 translateY(0)、scale(1) 这类终态，包含块依然成立，于是出现“动画都删了，遮罩还是不对”。

• transform: none 才算解除，translateY(0) 不算
• animation-fill-mode: forwards 或内联 style 会把终态锁住
• will-change: transform 即使当前没在动也可能触发
• filter: blur(0)、backdrop-filter 同理，只要值不是 none 就算
• contain: paint / layout / strict 一样会生成包含块，这条最容易被忽略

先确认它跟谁一起滚，再改代码

经验上一半以上的时间浪费在没确认参照物就删代码，删完发现是另一层在起作用。可以按四步走，顺序不建议打乱。

1. 定基准：给遮罩加一圈 outline，滚动页面看它跟着哪块元素一起动，先把参照物确认下来。
2. 查属性：从父级往上逐层看 computed 里的 transform、filter、perspective、will-change、contain、backdrop-filter，值非 none 的就是嫌疑层。
3. 隔离验证：只在嫌疑层上临时写 transform: none，看遮罩是否恢复全屏；一次只改一层，别同时动多处。
4. 定点修复：按业务选改动较小的改法，改完在 iOS Safari、安卓主流机型、微信内置浏览器各验一遍。

第 2 步要看 computed，而不是样式面板里写的声明，因为很多 transform 是动画库运行时挂上去的；第 3 步只是验证假设，不是最终方案。

四种改法：成本区间与各自的边界

• 做法 A：把动画下沉到内层内容块。外层容器保持干净，动效照旧。改动面小，常见区间 0.5~1 人天；适合动画只作用于首屏某块内容、表单卡片这类场景，不适合设计本身要求整块位移的动效。
• 做法 B：遮罩和弹窗一起挂到 body。用框架的传送门（React 的 createPortal、Vue 的 Teleport）渲染到 body 下，常见区间 1~3 人天，含样式作用域与 CSS 变量的核对；适合弹窗在多处复用的中后台项目，不适合强依赖父级变量和 scoped 样式的老代码。
• 做法 C：改用原生 dialog。showModal 进入浏览器顶层，不受祖先 transform 影响。新项目省事，常见区间 1~2 人天；老项目要先核对目标机型的支持情况与样式重置成本。
• 做法 D：动画结束就移除类名。成本更低，常见半天以内；但快速开关、连续点击时状态容易不同步，只适合临时兜底，不建议作为唯一方案。

横向比一下：A 改动面小、风险相对可控；B 收益更持久，代价是一轮样式作用域核对；C 长期维护成本偏低，前期要处理兼容。判断可以归成一句：动画只要还压在外层容器上，其他做法都只是绕；能下沉就下沉，下不了就让遮罩和弹窗一起走传送门。

交付现场：动效保住之后，多花的那半天

有个中后台项目，甲方要求首屏卡片保留“从上滑入”，预算只够一轮改稿，卡片里还嵌了第三方轮播组件。做法是把动画从整块容器下沉到卡片内容层，同时把详情抽屉改成 Teleport 挂到 body。动效保住了，遮罩也回到全屏；但抽屉内部有几个 CSS 变量写在父级作用域里，挂到 body 之后取不到，颜色和圆角全变了，又补了大约半天处理变量作用域，整体比预估晚了将近一天。这类返工的成本通常不在改代码本身，而在没提前核对遮罩和弹窗依赖了哪些变量与 scoped 样式——按经验区间看，额外耗时大致落在半天到一天，跟弹窗内部的样式耦合度成正比。

什么时候该查，什么时候不必折腾

需要上这套排查的情况大致三类：进场动画和外层容器绑在一起、弹窗或抽屉要覆盖整个视口、H5 嵌在 WebView 或小程序 web-view 里但浮层表现不一致。反过来也有可以直接跳过的场景。

• 不必上：只是偶尔一个轻提示，且祖先链上没有任何生成包含块的属性，直接调结构比排查更快
• 不必上：浮层由 App 原生层渲染，问题不在 CSS，翻祖先链没有意义
• 不必上：动画由 Canvas 或原生实现，根本不经过 CSS 包含块
• 先分清：如果遮罩位置和大小都对、只是被别的东西盖住或点不到，那多半是层叠上下文或事件透传的问题，和本文这条不是一回事

常见问题

把 transform 改成 none 了，遮罩为什么还是没铺满？

常见是终态被 fill-mode: forwards 或内联样式锁住，也可能是 will-change、filter 在起作用。先看 computed 的实际值，再逐层排除。

遮罩位置大小都对，只是点不到下面按钮，也是这个原因吗？

不一定。先确认遮罩是否真的铺满视口，再看层叠顺序和 pointer-events 的事件透传问题，这是另一条线。

用 Teleport 挂到 body 之后，弹窗样式全乱了怎么办？

多为样式作用域或 CSS 变量依赖父级所致。把变量提到 :root，或给弹窗单独一层根节点，通常比改回组件内渲染更省事。

小程序里同样的浮层被原生组件遮住，也按这套查吗？

方向不同。小程序原生组件层级高于普通视图，需要改用 cover-view 一类原生覆盖能力，祖先 transform 不是主要矛盾。

如果你手上正好是这个现象：先用描边确认遮罩跟谁一起滚，再顺着祖先链查 transform、filter、will-change、contain 这几个属性，确认根因后再挑改动较小的方案，别在高度和 z-index 上反复试。若浮层由原生层渲染，或页面本来就不涉及全屏浮层，这套排查可以直接跳过。