iOS Safari 的100vh为什么总是“不够高”？一文讲透视口单位的坑与解法
你有没有遇到过这样的情况：
在安卓手机上好好的一个全屏页面，到了 iPhone 的 Safari 浏览器里，底部莫名其妙留出一块空白？
或者用户点输入框时，软键盘弹出来，表单直接被顶到屏幕外，啥也看不见？
如果你用的是height: 100vh来做全屏布局，那大概率不是你的代码写错了 —— 是iOS Safari 对vh的理解，和你想的不一样。
这个问题看似小众，实则影响深远。从登录页、轮播图到聊天窗口，凡是依赖“占满整个屏幕”的交互设计，都可能在这上面栽跟头。更麻烦的是，它不像语法错误那样一眼就能发现，而是在特定设备、特定操作下悄然出现，等你发现时，用户早就流失了。
今天我们就来彻底拆解这个前端老生常谈却又屡踩不止的坑：为什么100vh在 iOS Safari 中不等于“全屏”？我们又能怎么解决？
你以为的100vh，其实是“理想中的全屏”
先复习一下基础知识。
CSS 视口单位中的vh，全称是viewport height，意思是“视口高度的 1%”。所以100vh理论上就是当前可视区域的完整高度。
听起来很合理，对吧？
但在 iOS Safari 中，这里的“视口”并不是你滚动页面时看到的那个动态变化的屏幕区域，而是浏览器在页面加载瞬间计算出来的一个“静态基准”。
具体来说：
- 当页面刚打开时，Safari 假设地址栏、底部工具栏都是可见的；
- 它基于这个“带 UI 元素”的状态去计算
1vh的像素值； - 即便你稍后开始滚动，这些 UI 自动隐藏了，
vh的换算比例也不会更新！
举个例子。一台 iPhone 14 的屏幕高度是 844px。但刚打开网页时，顶部导航栏 + 底部工具栏大约占掉 140px，于是 Safari 认为“有效视口”只有约 704px。
此时：
.full { height: 100vh; /* 实际 = 704px */ }结果就是：你想要一个全屏容器，但它只撑到了 704px，离真正的屏幕底部还差一截。
更讽刺的是，当你开始滑动页面，工具栏收起来了，可视区域变大了，可元素高度还是 704px —— 明明空间多了，内容却显得“不够用了”。
这就像按冬天最厚外套的尺寸买了衣柜格子，结果夏天衣服少反而空着一大块。
软键盘弹出？别指望vh会调整
如果说工具栏的问题还能勉强接受，那接下来这个才是真正致命的：当用户点击输入框，软键盘弹出时，100vh根本不会缩小！
对比来看：
- 在 Android Chrome 中，软键盘弹出会触发页面重排，
100vh会自动变成剩余可用高度（比如从 800px 缩到 400px），页面布局随之压缩，输入框通常能保持可见。 - 而在 iOS Safari 中，它选择“裁剪”而不是“缩放”—— 页面不动，直接挡住下半部分。而
100vh依然维持原来的数值。
后果是什么？
一个典型的登录表单，结构可能是这样：
<div class="login-page"> <header>Logo</header> <form class="form">...</form> <footer>版权信息</footer> </div>样式设置为：
.login-page { height: 100vh; display: flex; flex-direction: column; } .form { flex: 1; }理想中，.form区域会填满中间空白。可在 iPhone 上：
- 页面加载 →
100vh ≈ 704px - 用户点击密码框 → 键盘弹出，遮挡下半屏
.login-page仍高 704px，但实际可视区只剩 ~400px- 输入框正好落在键盘之上，完全不可见
用户根本看不到自己输的内容，体验极差。
这不是逻辑错误，也不是 DOM 结构问题 —— 是vh的语义和现实脱节了。
新一代视口单位来了：dvh才是真正的“动态高度”
为了解决这一顽疾，W3C 提出了新的视口单位家族：svh、lvh和最关键的dvh。
| 单位 | 含义 | 行为特点 |
|---|---|---|
svh | Small Viewport Height | 键盘完全展开时的高度（最小） |
lvh | Large Viewport Height | 页面初始加载时的高度（最大，含UI） |
**dvh** | Dynamic Viewport Height | 实时响应所有变化，真正反映当前可用高度 |
其中100dvh就是我们梦寐以求的“真实全屏”：无论你是横竖屏切换、工具栏收起，还是键盘弹出，它的值都会自动调整。
这意味着我们可以这样写：
.login-page { height: 100dvh; overflow-y: auto; }只要设备支持，表单就能始终适应当前可视区域，不再被遮挡。
✅ 支持情况（截至 2025 年初）
| 浏览器 | 是否支持dvh |
|---|---|
| Safari (iOS 16+ / macOS Ventura+) | ✅ |
| Chrome / Edge (Desktop & Android) | ✅ |
| Firefox | ❌（暂未实现） |
| iOS Safari < 16 | ❌ |
也就是说，在较新的苹果设备上已经可以放心使用，但为了兼容旧系统（如仍在使用的 iOS 14/15 设备），我们需要降级方案。
兼容性兜底：用 JS 动态注入真实视口高度
既然 CSS 层面无法保证vh准确，那就让 JavaScript 来补位。
核心思路很简单：
用
window.innerHeight获取真实的可视高度，转换成每1vh对应的像素值，写入 CSS 变量，然后在样式中引用这个变量。
因为window.innerHeight在 iOS Safari 中是动态更新的 —— 不管是旋转屏幕、滚动隐藏 UI，还是键盘弹出，它都能准确反映当前可用高度。
实现代码如下：
function updateViewportHeight() { // 获取当前 1vh 相当于多少像素 const vh = window.innerHeight * 0.01; // 设置为根元素的自定义属性 document.documentElement.style.setProperty('--vh', `${vh}px`); } // 初始化 updateViewportHeight(); // 监听窗口大小变化（如横竖屏切换） window.addEventListener('resize', updateViewportHeight); // 特别重要：监听聚焦事件（键盘弹出） document.addEventListener('focusin', updateViewportHeight); // 键盘弹出 document.addEventListener('focusout', updateViewportHeight); // 键盘收起然后在 CSS 中替换原来的100vh：
.fullscreen-layout { /* 如果 --vh 存在，使用其计算值；否则回退到标准 1vh */ height: calc(100 * var(--vh, 1vh)); }这样一来：
- 新设备优先使用
--vh，获得精准高度； - 老设备或禁用 JS 的场景下，至少还有
1vh可用； - 配合事件监听，真正做到“动态响应”。
💡 小技巧：如果你担心频繁触发性能问题，可以用
requestAnimationFrame或简单节流包装一下updateViewportHeight函数。
如何优雅地融合dvh与 JS 方案？
最好的做法是：优先尝试原生能力，失败则降级到 JS 补偿。
利用 CSS 的@supports查询，我们可以智能切换：
/* 默认使用 JS 提供的动态 vh */ .full-height { height: calc(100 * var(--vh, 1vh)); } /* 若浏览器支持 dvh，则启用原生动态单位 */ @supports (height: 100dvh) { .full-height { height: 100dvh; /* 同时移除 JS 注入的影响，避免冲突 */ height: 100dvh !important; } }JavaScript 端也可以做一次检测，决定是否需要绑定事件：
if (!CSS.supports('height', '100dvh')) { // 不支持 dvh 才启用 JS 动态更新 setupDynamicVH(); }这样既减少了不必要的运行时开销，又确保了最佳兼容性。
实战建议：哪些场景必须避开100vh？
以下几类组件尤其容易受此问题影响，务必谨慎处理：
1. 登录 / 注册表单页
- ❌ 避免直接
height: 100vh - ✅ 使用
calc(100 * var(--vh))或100dvh
2. 全屏轮播（Swiper）
- 轮播项高度若固定为
100vh，在 iPhone 上会出现上下黑边 - ✅ 建议给容器加
overflow: hidden，并用 JS 控制实际高度
3. 底部弹窗（Bottom Sheet）
- 弹窗内部若有滚动内容，需确保其最大高度不超过可用视区
- ✅ 使用
max-height: 90dvh或结合--vh动态设定
4. 聊天界面
- 输入框区域必须随键盘动态调整位置
- ✅ 利用
focusin事件触发布局重算，或将输入区固定在视口底部
开发者避坑清单
✅推荐做法：
- 永远不要假设
100vh == 屏幕高度，尤其是在移动端； - 对涉及输入的页面，必须测试键盘弹出后的表现；
- 使用
@supports+dvh作为未来方向； - 用
--vh+ JS 作为当前主力兼容方案； - 在 React/Vue 中，记得在组件卸载时清除事件监听，防止内存泄漏。
⚠️常见误区：
- 只监听
resize事件 ——iOS Safari 中键盘弹出不会触发 resize！ - 用
setTimeout延迟更新 —— 容易造成闪跳或错位； - 忽略横屏测试 —— 横屏时工具栏占比不同，行为也可能异常；
- 过度依赖第三方库 —— 很多 UI 组件内部仍硬编码
100vh，需自行 patch。
写在最后：标准在进步，但我们还得自己铺路
dvh的出现，标志着浏览器厂商终于正视了移动场景下的真实需求。随着 iOS 16+ 渗透率不断提升，我们有望在未来几年逐步告别这个困扰多年的“vh陷阱”。
但在今天，仍有大量用户运行着旧版系统。作为开发者，我们不能坐等环境完美，而要学会在现实限制中构建稳健的体验。
记住一句话：
在移动端适配中，最危险的假设，就是相信“标准行为”一定会被遵守。
而最有效的应对方式，就是：
用 CSS 描述意图，用 JS 保障结果。
当你下次再想写下height: 100vh时，不妨多问一句：
“我写的这个‘全屏’，真的能被用户看见吗？”
