发布时间：2025年6月 | 分类：前端开发技巧

作为一名在代码堆里摸爬滚打多年的前端开发者，你一定有过这种经历：在一个慵懒的下午，你刚刚写完一个自认为完美的全屏着陆页。在 PC 端的 Chrome 调试模式下一切kan起来dou是那么赏心悦目，布局严丝合缝，色彩搭配和谐。你自信满满地拿起手机，准备在真机上验收成果，结果——

那个该死的滚动条出现了！

或者geng糟糕，底部的按钮被那个忽隐忽现的浏览器地址栏给无情地截断了。那一刻，你的心情可Neng比喝了过期的咖啡还要糟糕。明明 CSS 里写得清清楚楚 height: 100vh，为什么到了移动端就变成了这副德行？

今天我们就来好好聊聊这个让无数开发者抓狂的“视口高度”问题，顺便kankan为什么你应该毫不犹豫地把 100vh 扔进垃圾桶，拥抱新的解决方案。

为什么 100vh 在移动端“撒谎”了？

要搞清楚这个问题，我们得先回到定义本身。在 CSS 的规范里vh 是视口高度单位。逻辑上讲，1vh 就等于当前视口高度的 1%。那么100vh 理所应当就是屏幕可见区域的 100%。

在 PC 端，这确实没毛病。浏览器窗口通常是固定的，除了调整窗口大小，视口高度不会发生什么戏剧性的变化。但是移动端的世界完全是另一番景象。

现在的移动浏览器，无论是 Safari 还是 Chrome，为了给用户腾出geng多的浏览空间，dou采用了动态工具栏的设计。这意味着，当你向下滑动页面时顶部的地址栏和底部的导航栏会悄悄滑出屏幕；当你向上滑动时它们又会滑回来。

这就导致了一个尴尬的局面：浏览器厂商对于“视口”的定义，和我们所理解的“可见区域”出现了偏差。

关键点来了：大多数移动端浏览器将 100vh 定义为“Zui大视口高度”，也就是当地址栏和工具栏完全收起、隐藏时的理论高度。

想象一下当页面初始加载时浏览器的地址栏还赫然在目。此时屏幕实际可见的高度其实是小于 100vh 的。因为你的元素被强制设定为了那个“Zui大高度”，结果就是内容溢出了于是那个令人抓狂的滚动条就出现了。这就好比你试图把一张大桌子硬塞进一个小房间，多余的部分只Neng突在外面。

曾经的“土办法”：JavaScript 补丁

在hen长一段时间里为了填平这个坑，前端社区流传着各种基于 JavaScript 的“黑魔法”。我也曾无数次在项目中复制粘贴过类似的代码。

思路其实hen简单：既然 CSS 的 vh 不靠谱，那我们就用 JS 来获取真实的窗口高度，然后通过 CSS 变量传给样式。

function setRealVH {
  // 获取当前窗口的内部高度，这才是用户真正Nengkan到的像素
  const vh = window.innerHeight * 0.01;
  // 将其设置为 CSS 变量
  document.documentElement.style.setProperty;
}
// 页面加载时设置一次
window.addEventListener;
// 窗口大小改变、或者屏幕旋转时必须重新计算
window.addEventListener;

然后在 CSS 里这样写：

.fullscreen-element {
  /* 使用计算出的变量，而不是固定的 100vh */
  height: calc * 100);
}

这个方案确实有效，它像一块创可贴，暂时止住了血。但是作为一名有追求的工程师，你难道不觉得这hen繁琐吗？

你需要引入额外的 JavaScript 逻辑，这增加了页面的加载负担和复杂度。resize 事件的触发时机和频率也是个麻烦事，处理不好可Neng会导致页面闪烁或布局抖动。Zui让人头疼的是当用户滚动页面地址栏伸缩时JS 方案往往无法实时、平滑地响应这种变化。元素的高度通常是固定的，除非你疯狂地监听 scroll 事件。

时代的眼泪：告别 JS，拥抱 CSS 新特性

谢天谢地，CSS 工作组的大佬们终于听到了来自一线开发者的呐喊。为了彻底解决这个老大难问题，CSS Values and Units Module Level 4 引入了一套全新的动态视口单位。

这才是我们真正需要的“银弹”。它们不仅解决了兼容性问题，还带来了丝般顺滑的体验。

认识新朋友：svh, lvh, dvh

这套新规把视口高度拆分得geng细致了主要包含以下三个“主角”：

svh : Zui小视口高度。也就是浏览器地址栏和工具栏dou展开时的可见高度。Ru果你希望内容永远不被遮挡，哪怕工具栏挡住了视线也要显示，用这个。

lvh : Zui大视口高度。也就是所有浮动 UI dou隐藏时的屏幕高度。这其实和传统的 100vh 比较像。

dvh : 动态视口高度。这是今天的 MVP！它代表了当前瞬间的实际可见高度。

为什么 dvh 是终极答案？

dvh 的强大之处在于它的“动态”二字。它不关心地址栏是显示还是隐藏，它只关心“现在”。

当你使用 height: 100dvh 时神奇的事情发生了：

当地址栏滑出，占据屏幕空间时dvh 的值会自动变小，你的元素高度随之收缩，完美适配剩余空间，没有多余的滚动条。当地址栏收起，腾出空间时dvh 的值又会自动变大，元素平滑地伸展填满屏幕。

整个过程完全由浏览器引擎在底层处理，不需要你写一行 JavaScript 代码去干预，也没有布局抖动。那种感觉，就像是从换挡顿挫的手动挡升级到了平顺无比的电动车。

.fullscreen-element {
  /* 以前的Zuo法 */
  /* height: 100vh; */ 
  /* 现在的Zuo法 */
  height: 100dvh; 
  /* 或者，Ru果你有特殊需求 */
  /* height: 100svh;  固定Zui小高度，防止被遮挡 */
}

兼容性：现在Ke以放心用了吗？

kan到这里hen多保守的朋友可Neng会问：“这玩意儿听起来hen美，但是我的用户还在用上古浏览器怎么办？”

这确实是个好问题。Ru果是两三年前，我可Neng会劝你谨慎。但是现在是 2025 年了！

让我们kan一组数据：从 2023 年开始，所有主流的现代浏览器——Safari, Chrome, Edge, Firefox——douYi经全面支持了这些新的视口单位。特别是那个曾经让无数前端头疼的 iOS Safari，也在较新的版本中跟进支持了 dvh。

除非你的项目明确要求支持 Android 4.4 或者 IE 11，否则你完全Ke以放心大胆地在生产环境中使用 100dvh。

当然为了以防万一，你还Ke以Zuo一个极其简单的降级处理：

.my-cool-fullscreen-section {
  /* 现代浏览器享受丝滑体验 */
  height: 100dvh;
  /* Ru果不支持 dvh，回退到传统的 vh */
  height: 100vh; 
}

因为 CSS 的层叠特性，浏览器会优先应用它支持的第一个属性。这样写，既照顾了前沿体验，又兜住了老旧设备的底。

别再跟浏览器较劲了

回顾一下我们为了解决移动端全屏布局的问题，走了不少弯路。从Zui初的一头雾水，到后来依赖 JavaScript 的 window.innerHeight 算法，再到如今 CSS 原生支持的 dvh，前端开发的体验正在变得越来越好。

技术总是在进步的，我们的代码库也应该随之进化。那些为了修补浏览器缺陷而存在的冗余 JS 代码，是时候从项目中清理出去了。

所以下次当你需要实现一个占满屏幕的欢迎页、一个沉浸式的弹窗蒙层，或者一个 fixed 定位的底部菜单时请记住：别再用 100vh 了。直接上 100dvh，然后去喝杯咖啡，享受一下没有 Bug 的下午吧。

毕竟我们的时间应该花在创造geng酷炫的交互上，而不是跟浏览器的地址栏较劲，你说对吧？

---