iOS Safari中fixed遮罩“漏底”的根本原因与可靠解法
在移动端开发中，实现一个全屏遮罩听起来是基础需求，但很多开发者都曾在iOS Safari上栽过跟头——明明设置了position: fixed和height: 100vh，遮罩却总在底部“漏”出一截内容，或者横竖屏切换后高度错乱。这背后的根本原因，其实出在视口单位的计算逻辑上：vh单位在iOS Safari中会将地址栏高度计入视口，但fixed元素的渲染却不实时响应地址栏的收起与展开。这就导致了计算基准与渲染基准的错位。那么，最可靠的解法是什么？答案是：放弃对CSS单位的幻想，转而使用Ja vaScript动态设置height = window.innerHeight，并同时锁定body的滚动。
为什么 position: fixed 遮罩在 iOS 上经常“漏底”
问题根源在于Safari，尤其是旧版iOS，对fixed定位元素的视口计算有一套独特的“逻辑”。它并非始终相对于浏览器窗口，而是依赖于当前的滚动位置和页面缩放状态。一旦页面可以滚动，或者触发了iOS特有的“弹性滚动”效果，fixed元素就可能脱离掌控——它可能不再覆盖整个可视窗口，而是错误地相对于某个祖先容器定位，甚至被直接截断。
- 常见错误现象：使用
height: 100vh在iOS Safari中实际渲染的高度小于屏幕，导致遮罩下方露出背景内容；另一个典型场景是横屏切回竖屏后，遮罩的高度计算发生错乱。 - 根本原因：如前所述，
vh单位在计算时包含了动态的地址栏或工具栏高度，但fixed元素在渲染时，并不会跟随地址栏的收起或展开而实时更新其布局参考系。 - 兼容性影响：iOS 15及以上版本对这一问题有所改善，但iOS 14及更早的版本，以及部分基于旧版WKWebView的微信内置浏览器中，问题依然严重存在。
用 100svh 替代 100vh 是最简解法吗
答案是否定的。虽然svh（small viewport height）是CSS Viewport Units Level 2规范中引入的新单位，理论上它能避开动态工具栏的干扰，只计算“稳定”的视口高度，但它在Safari中的支持度目前非常不理想。直到iOS 16.4+才开始实验性支持，并且还需要开启viewport-fit=cover这样的元标签配置。对于需要广泛兼容的生产环境而言，这显然不是一个可靠的方案。
- 使用场景：它仅适用于那些明确只运行在iOS 17+或macOS Sonoma+以上系统，且开发者能够完全控制WebView配置的新应用内嵌页面。
- 参数差异：简单来说，
100svh指的是“用户当前可见区域的静态高度”，而另一个更理想的单位100dvh（dynamic viewport height）能动态适应工具栏变化，但遗憾的是，Safari目前完全不支持它。 - 实操建议：现阶段不要把
svh作为主要解决方案来依赖。它就像一个半成品的开关，即便在某些条件下能打开，也随时可能失效，带来更多不确定性。
真正可靠的全屏遮罩写法（含防滚动穿透）
那么，什么才是经得起考验的方案？核心思路是：放弃纯CSS的高度声明，转而使用Ja vaScript动态读取window.innerHeight这个精确的视觉视口高度，并将其直接写入元素的内联样式。同时，必须处理好滚动穿透问题。
- 基础定位：遮罩元素必须设置
position: fixed; top: 0; left: 0; width: 100%;。但关键点在于高度——不要用vh，也不要幻想fixed能自动填满。 - 动态高度控制：通过JS设置：
element.style.height = window.innerHeight + ‘px’。这能确保高度始终等于当前可视窗口的精确像素值。 - 防滚动穿透：需要双管齐下。首先，设置
document.body.style.overflow = ‘hidden’来禁止页面滚动；其次，为遮罩元素加上touch-action: none，这能有效防止iOS上的拖拽手势穿透遮罩，触发底层内容滚动。 - 响应视口变化：必须监听
resize事件（如横竖屏切换、浏览器窗口调整）来重新设置高度。为了避免性能问题，可以使用setTimeout进行简单的防抖处理。
const overlay = document.getElementById(‘overlay’);
function updateOverlayHeight() {
overlay.style.height = window.innerHeight + ‘px’;
}
window.addEventListener(‘resize’, updateOverlayHeight);
updateOverlayHeight(); // 初始化执行一次
微信 / QQ 内置浏览器里的隐藏坑
到了微信、QQ这类内置浏览器环境，情况往往更复杂。它们的WebView常常将页面包裹在iframe或自定义容器中，这导致window.innerHeight返回的可能是外层容器的高度，而非设备的真实屏幕尺寸。结果就是，遮罩要么过高盖住了不该盖的部分，要么过矮依然“漏底”。
立即学习“前端免费学习笔记（深入）”；
- 常见错误现象：遮罩看似覆盖了整个页面，但顶部留有神秘白边，或者底部溢出一截，导致点击区域完全错位。
- 解决路径：可以优先尝试使用
document.documentElement.clientHeight。如果这个值仍然不准，再降级使用screen.height作为兜底方案。需要注意的是，screen.height是设备屏幕的物理像素高度，精度较低且不会随窗口变化，但至少能保证遮罩不漏。 - 性能影响：读取
screen.height本身开销极低，但要避免在scroll等高频事件中读取它——因为它根本不会变化，重复读取毫无意义。 - 关键提醒：微信Android版采用的X5内核，对
fixed的支持甚至比iOS Safari还要差。如果遮罩涉及动画，务必加上will-change: transform来强制开启硬件加速，否则会出现明显的卡顿。
说到底，在实际项目中，一个遮罩能否真正做到“全屏”，往往取决于那些容易被忽略的细节：你有没有在页面滚动后重新测量高度？有没有监听横竖屏切换并重置？有没有为微信X5内核准备单独的补丁代码？这些细节如果不写进代码里，光靠CSS属性是绝对“盖”不住的。
