【2026】 LLM 大模型系统学习指南
2026/1/16 11:22:51
深度解析CSSvh单位：为什么你的全屏布局在手机上“出问题”了？
你有没有遇到过这样的情况？
在电脑上调试得好好的一个全屏登录页，用height: 100vh实现完美居中，结果一拿到 iPhone 上预览——底部被裁掉了一截，输入框还被键盘盖住。更离谱的是，页面明明没滚动条，用户却说“下面点不到”。
这不是代码写错了，而是你踩中了现代前端开发中最隐蔽、最普遍的坑之一：CSS 的vh单位在不同设备上的行为差异。
尤其在移动端 Safari 和 Chrome 中，100vh并不等于“我看到的屏幕高度”。这个看似简单的单位背后，藏着浏览器对“视口”定义的复杂逻辑。今天我们就来彻底讲清楚这个问题，并给出真正可用的解决方案。
从一个真实 Bug 开始说起
先看一段再普通不过的代码：
.fullscreen { height: 100vh; display: flex; align-items: center; justify-content: center; background: #0d1b2a; color: white; }<div class="fullscreen"> <p>欢迎登录</p> <input type="text" placeholder="请输入用户名"> </div>这段代码本意是做一个居中的登录界面。在桌面浏览器里运行良好，但在 iPhone 的 Safari 上打开时，你会发现：
- 初始加载时，输入框靠近底部，但似乎位置偏高；
- 点击输入框弹出键盘后，整个页面没有缩放，输入框直接被键盘挡住；
- 向上稍微一滑，地址栏自动隐藏，此时你会发现背景色只覆盖了部分屏幕，下方出现空白。
这到底是为什么？
答案是：100vh在移动端并不是动态变化的可视高度。
vh到底是什么？别再误解它了
vh是viewport height的缩写，1vh = 视口高度的 1%。所以100vh就应该是“整个屏幕的高度”，对吧？
理论上没错。但关键在于——“视口”到底指哪一块？
桌面端：一切如你所想
在 PC 浏览器中，视口就是浏览器窗口的渲染区域（不含任务栏、标签页等操作系统 UI）。当你调整窗口大小时，vh会实时更新，触发重排和重绘。
比如窗口高 800px，那么1vh = 8px，100vh = 800px。简单直观。
移动端：真相远比你想得复杂
移动浏览器为了兼容传统网页，默认使用一个“虚拟”的布局宽度（通常是 980px），并通过<meta name="viewport">来控制缩放行为。而这里的“视口”其实有三种概念：
| 类型 | 含义 | 是否影响vh |
|---|---|---|
| 布局视口（Layout Viewport） | CSS 布局参考的容器尺寸 | ✅ 是 |
| 视觉视口（Visual Viewport） | 用户当前实际看到的部分 | ❌ 否 |
| 理想视口（Ideal Viewport） | 设备推荐的最佳显示尺寸 | ⚠️ 间接相关 |
重点来了：vh是基于“布局视口”的高度计算的，但它不会随着用户滚动导致浏览器 UI 隐藏/显示而动态改变。
举个例子：
- iPhone 13 屏幕物理高度为 852px；
- Safari 加载页面时，浏览器工具栏是可见的，占用约 100px；
- 此时布局视口高度约为752px，于是100vh = 752px；
- 当你开始滚动，地址栏和底部工具栏自动收起，可视区域变成812px；
- 但100vh还是 752px！不会变！
这就造成了一个问题：你用100vh设置的高度，实际上小于用户真正能看到的空间。当内容居底或涉及输入时，就会出现遮挡、留白、交互失效等问题。
不只是 iOS，Android 也有类似问题
很多人以为这是 Safari 特有的 bug，其实不然。
Chrome on Android 的处理机制略有不同：某些版本会在工具栏隐藏后重新计算vh，但存在延迟或抖动。而且软键盘弹出时，系统并不会总是缩小视口，反而可能以“覆盖模式”呈现，导致100vh完全没考虑键盘占据的空间。
结果就是：无论 iOS 还是 Android，依赖100vh实现精确垂直定位的组件都容易翻车。
如何解决？这里有三个层级的方案
面对这个问题，我们可以从“未来式”、“现在式”到“兼容式”逐步推进。
✅ 方案一：拥抱未来 —— 使用dvh（推荐）
现代浏览器已经意识到这个问题，并推出了新的动态视口单位（dynamic viewport units）：
| 单位 | 含义 |
|---|---|
dvh | dynamic viewport height，随工具栏显隐动态变化 |
svh | small viewport height，工具栏完全显示时的最小高度 |
lvh | large viewport height，工具栏完全隐藏时的最大高度 |
其中最实用的就是dvh。它的值会根据用户的操作实时调整，完美匹配当前的实际可视高度。
.fullscreen { height: 100dvh; display: flex; align-items: center; justify-content: center; }就这么改一行，就能解决绝大多数移动端适配问题。
🔍 支持情况（截至 2024 年末）：
- ✅ Safari 15.4+（iOS 15.4 / iPadOS 15.4）
- ✅ Chrome 67+（Android）
- ⚠️ Firefox：部分支持，需测试
- ❌ 其他旧浏览器：不支持
👉 参考： Can I use – dvh
虽然不能全覆盖，但dvh已经成为行业趋势。我们完全可以把它作为默认选择，再为老浏览器提供降级方案。
✅✅ 方案二：JavaScript 动态注入变量（生产环境首选）
对于还不支持dvh的浏览器，我们可以手动模拟它的行为。
核心思路是：用 JavaScript 获取真实的可视高度window.innerHeight，并将其转换为 CSS 可用的单位。
function setDynamicVH() { // 获取 1vh 对应的像素值 const vh = window.innerHeight * 0.01; // 设置为根元素的 CSS 变量 document.documentElement.style.setProperty('--vh', `${vh}px`); } // 初始化 setDynamicVH(); // 监听变化：窗口 resize、方向旋转、甚至滚动（某些情况下需要） window.addEventListener('resize', setDynamicVH); window.addEventListener('orientationchange', setDynamicVH);然后在 CSS 中这样使用：
.fullscreen { height: calc(var(--vh, 1vh) * 100); /* 默认回退到 1vh */ background: #0d1b2a; }✅优点：
- 精准反映实际可视区域；
- 自动响应工具栏显隐、横竖屏切换；
- 回退机制完善，无兼容性风险。
⚠️注意点：
- 频繁触发resize可能影响性能，建议加节流（throttle）；
- 某些 Android 浏览器在键盘弹出时不触发resize，需结合focus/blur补充监听。
这是一个已经被广泛验证的方案，在很多 PWA 和 H5 活动页中稳定运行多年。
🛠️ 方案三：保守兜底 —— 媒体查询 + 容错设计
如果你的项目不允许引入 JS 或无法支持新特性，也可以采用一些“经验性”的补偿策略。
例如，针对小屏幕设备适当减少高度：
/* 针对常见手机屏幕做微调 */ @media (max-height: 700px) and (max-width: 500px) { .fullscreen { height: 90vh; /* 留出空间给工具栏 */ } }或者避免让重要内容紧贴底部：
.container { min-height: 100vh; padding-bottom: env(safe-area-inset-bottom, 20px); box-sizing: border-box; }这里用了env(safe-area-inset-bottom)，可以避开 iPhone 的圆角和 Home Indicator 区域，防止内容被遮挡。
这类方法不够精准，但在紧急修复或低优先级页面中仍可作为临时手段。
实战建议：什么时候该用vh？怎么用才安全？
理解原理之后，我们还需要知道如何正确应用。
✅ 推荐使用场景
| 场景 | 建议写法 | 说明 |
|---|---|---|
| 全屏轮播图 | height: 100dvh | 视觉冲击强，需撑满屏幕 |
| 登录/注册页 | min-height: 100dvh | 避免键盘弹出时强制压缩 |
| 弹窗/抽屉组件 | max-height: 80dvh | 控制最大高度，防溢出 |
| 视频播放容器 | aspect-ratio: 16/9; height: 100dvh | 结合比例锁死布局 |
⚠️ 高风险用法（尽量避免）
- ❌ 把
html, body { height: 100vh }当作通用初始化（可能导致嵌套滚动异常） - ❌ 在表单页中用
100vh固定容器高度（键盘弹出会破坏体验） - ❌ 仅依赖
100vh实现“底部按钮固定”（应使用position: fixed或flex + auto margin）
最佳实践总结
经过大量项目验证，以下是我们在团队内部推行的规范：
默认使用
100dvh
所有需要全屏高度的地方，优先写成100dvh，哪怕暂时只有部分浏览器支持。必须搭配 JS fallback
注入--vh变量，确保旧设备也能获得接近一致的体验。慎用于输入相关布局
软键盘的行为太不可控，优先考虑弹性布局而非固定高度。结合
safe-area-inset使用
特别是在 iOS 上，加上安全区域边距能显著提升可用性：
css body { padding-bottom: env(safe-area-inset-bottom); }
- 测试一定要覆盖真机
DevTools 的设备模拟器无法还原工具栏动态变化的真实过程，务必在 iPhone 和安卓机上实测。
写在最后：技术演进中的取舍与坚持
vh看似只是一个长度单位，但它折射出的是前端开发中一个永恒的主题：理想标准与现实兼容之间的博弈。
我们希望用最简洁的 CSS 实现完美的跨设备体验，但浏览器厂商各自的实现细节却常常打破这种幻想。
幸运的是，标准正在进步。dvh的出现意味着 W3C 和主流浏览器已经开始正视这个问题。作为开发者，我们要做的不是回避vh，而是学会在正确的时机使用合适的工具。
下一次当你写下height: 100vh时，请多问一句：
“我想要的，真的是这个‘视口’吗？”
如果你也在构建 H5 页面、PWA 应用或移动端弹窗组件，不妨试试100dvh + --vh fallback的组合拳。你会发现，那些曾经令人头疼的“底部消失”问题，终于得到了优雅的终结。
💬互动时间：你在项目中是否也遇到过vh导致的布局错乱？你是怎么解决的？欢迎在评论区分享你的经验和踩过的坑！