企业官网建设流程全解析

1. 为什么移动端浏览器里的100vh会"说谎"

1.1 视口单位背后那套尺寸逻辑

先明确一个概念：vh这个单位，在规范里定义为"视口的初始包含块高度的1%"。听起来很严谨对吧？问题就出在"视口的初始包含块"这个描述上——在PC端浏览器里，视口高度就是窗口高度，1vh等于窗口高度的1%，准确得让人毫无戒心。可一旦到了移动端，浏览器的窗口本身就不是一个固定概念。

以iPhone Safari为例，你手指向上滑动页面时，底部导航条会收起来，地址栏会缩上去，可视区域的垂直方向瞬间多出几十像素。如果此时页面里有个元素设置了height: 100vh，在滑动的过程中浏览器是"假装"整个视口一直都是最大高度，还是实时跟随可视区域变化？不同浏览器给出的答案不一样，而且都算不上完美。

说得直白一点：100vh在移动端表示的是"浏览器认为的视口高度"，而不是"用户此刻眼睛能看到的高度"。这两者之间的差值，就是地址栏、底部工具栏、浏览器自带的安全区域这些元素所占用的空间。于是经典的悲剧就出现了——一个height: 100vh的弹层、底部导航栏或者首屏区块，在移动端打开时会有一部分内容被浏览器UI遮住，或者底部多出一截空白，怎么调都不对劲。

1.2 地址栏伸缩带来的连锁反应

我印象最深的一次事故，是做一个移动端落地页的首屏要求"必须铺满一屏"。当时我直接给容器写了min-height: 100vh，在Chrome DevTools的设备模拟器里看，稳稳的一整屏，完美。结果用iPhone真机一测，页面往下滑动时，底部导航栏收起来，整个页面背景色和下一屏的内容衔接处出现了一条明显的断裂带——背景没铺到底。

原因不复杂：页面加载时浏览器的地址栏处于展开状态，Safari把100vh按"地址栏展开时的最大视口高度"计算了。用户一滚动，地址栏收起，可视区域变高，但那个容器的高度已经定死了，不会再跟着变。反过来的场景同样存在：某些Android浏览器在初始化时按最小视口算，导致100vh内容在地址栏收起后反而留出一大截空白。

这个"滚动即变"的特性，就是移动端视口问题最恶心的点：它不只是初次加载时的计算偏差，而是整个交互过程中随时可能变化的动态问题。

1.3 先把问题定性：你要的到底是"最大"还是"当前"

在找解决方案之前，我建议先停下来问自己一个问题：你这个100vh想表达的语义是什么？

• 如果是"这屏内容至少占满整个浏览器窗口的最大可用高度"，那你要的是large viewport，也就是lvh。
• 如果是"这屏内容要贴合用户当前看得到的可视区域，随时跟着伸缩"，那你要的是dynamic viewport，也就是dvh。
• 如果只是"在初始加载时铺满一屏，后续滚动状态不管"，那small viewport的svh可能更合适。

很多人在网上搜"100vh兼容方案"，上来就找代码抄，结果抄来抄去发现时而好用时而翻车，根本原因就是没搞清楚自己这个页面要哪种语义。这个判断做错了，后面用什么方案都是错。

2. 那些年我们用过的"伪解决方案"，逐个拆解

2.1 window.innerHeight + JS手动计算

这是最老派的方案，核心思路是拿到浏览器当前可视高度，塞给一个CSS自定义属性，再在滚动、resize、orientationchange时重新计算：

function setViewportHeight() { const vh = window.innerHeight * 0.01; document.documentElement.style.setProperty('--vh', `${vh}px`); } window.addEventListener('resize', setViewportHeight); window.addEventListener('orientationchange', setViewportHeight); setViewportHeight();

.container { height: calc(var(--vh, 1vh) * 100); }

这套方案在2017年前后相当流行，现在很多老项目里依然能看到。它比纯100vh强不少，因为window.innerHeight在iOS Safari里返回的是"当前可视区域高度"（地址栏折叠后数值会变化），跟着resize事件走，能适应大部分滚动场景。

但它的缺陷也很明显。第一，resize事件在移动端的触发时机并不稳定，尤其Android机型上，地址栏变化、软键盘弹出、底部手势条变化有时只会触发visualViewport的resize，而window.innerHeight的更新会慢半拍，导致布局闪烁。第二，在PC端浏览器窗口缩放时，这套JS每触发一次都会强制一次样式重计算，如果页面上还有别的动画，帧率会肉眼可见地掉。第三，orientationchange在iOS上已经废弃了，新系统里两段式旋转会把计算搅乱一阵子。

结论：这不是一个"错误"的方案，但它的生命周期已经到头了，属于"能用但不优雅"的过渡产物。如果你还在维护老代码，看到这个写法不用急着重构，但如果是从零开始的新项目，我不推荐再这么写。

2.2 百分比高度 + calc() 的折中方案

另一个常见思路是放弃vh，改用html, body { height: 100% }一路往下的百分百继承链：

html, body { height: 100%; } .container { height: calc(100% - 60px); /* 减去固定头部 */ }

这个方案在"页面本身不滚动，内容锁定在一屏内"的场景下是可行的。比如一些移动端的引导页、抽奖页、全屏活动页，结构简单，滚动逻辑不多，用百分比继承反而比vh稳定——因为它是纯CSS计算，不依赖JS。

问题出在继承链上。只要中间某个父元素没有设置高度，百分比就失效。而且这个方案意味着你的布局结构被死死绑定——所有祖先元素都必须显式声明高度，一旦某个容器需要改用min-height或者flex布局撑开内容，整条继承链瞬间断裂。我见过不少项目就是因为后人改了某个父级的高度策略，导致满屏页面突然从底部漏出背景色。

2.3 -webkit-fill-available：曾经的小众救命稻草

.container { height: -webkit-fill-available; }

这个写法在iOS Safari上确实有效，因为Safari对fill-available的实现逻辑接近"扣除浏览器UI后的剩余空间"。它在老版本的iPhone上解决过不少问题，至今在一些H5页面里还能看到。

但它的致命伤是：W3C规范里从来没有一个叫-webkit-fill-available的标准值，它是最早fill-available提案的浏览器私有实现，现在Chrome虽然也能解析带前缀的版本，但行为和Safari并不完全一致。而且它只解决了height这一个维度，width场景、min-height场景、多个元素叠加计算的场景都照顾不到。拿它当主力方案风险太大，我自己的态度是：只能作为兼容性兜底，绝不能作为主方案。

2.4 为什么需要重新审视问题根源

说了这么多，你会发现一个共性：所有"伪解决方案"本质上都是在"手动修补视口计算差异"。JS方案用运行时高度覆盖CSS视图单位，百分比方案绕开视口单位回到文档流，fill-available方案直接换一套计算模型——它们都没有正面回答那个最核心的问题：浏览器到底应该根据什么来定义"视口高度"。

真正的转机在于，CSS规范在2022年的Viewport Units Level 4里正式引入了动态视口单位族，让"持续变化"这件事第一次有了原生语言层面的表达方式。这就是下一节要展开的内容。

3. 动态视口单位：dvh / svh / lvh 的正确打开方式

3.1 三种单位的语义差异

规范把移动端浏览器的视口高度分成了三个状态：小的（small）、大的（large）、动态的（dynamic）。

• svh：小视口高度，对应浏览器UI全部展开时的视口。地址栏占着位置、底部导航条占着位置，可视区域最矮的那个状态。
• lvh：大视口高度，对应浏览器UI全部收起时的视口。可视区域最高的那个状态。
• dvh：动态视口高度，跟随浏览器UI的伸缩实时变化。地址栏展开时它等于svh，地址栏收起时它等于lvh。

翻译成实际开发语义：

.container { height: 100vh; /* 旧写法：含义模糊，移动端容易出错 */ height: 100dvh; /* 新写法：一直贴合当前可视区域 */ }

注意CSS的层叠规则——把100vh写在100dvh上面，是为了让不识别dvh的老浏览器自动回退到vh，而支持dvh的现代浏览器会用后面的声明覆盖前面的。这个"渐进增强"策略是行业里的标准做法，也是我目前在新项目里最推荐的写法。

3.2 支持范围和一份诚实的兼容性说明

把话说透：dvh不是"万国表"，它也有兼容性边界。

• iOS Safari 15.4 及以上完整支持，也就是说iPhone 8等较早设备升级到iOS 15.4之后就能用。
• Chrome 108 及以上支持，覆盖了绝大多数现代Android机型。
• Firefox 101 及以上支持，桌面端和Android版都包括在内。
• UC、QQ浏览器这类国内壳浏览器，基于较新Chromium内核时没问题，但老版本仍有风险。

所以在实际项目中，我的标准姿势是这样的：

.hero { height: 100vh; /* 兜底：所有浏览器都认识 */ height: 100svh; /* 兜底：优先使用小视口，保证内容不会被遮挡 */ height: 100dvh; /* 进阶：支持动态视口的浏览器获得最佳体验 */ }

这里有个值得思考的细节：回退值为什么是svh而不是lvh？因为在拿不准浏览器行为的时候，"稍微矮一点"比"稍微高一点"安全——内容不够铺满也就漏一点背景色，内容超出屏幕的话，用户可能会以为页面出bug了。svh保证的是内容永远在最小可视区域内完整可见，这个方向在移动端是更稳妥的选择。

3.3 使用动态视口单位时的几个注意点

第一，dvh在页面滚动过程中是"会变的"，这其实是它的核心优势，但也会带来一个微妙的问题：如果页面上有固定定位的元素用了height: 100dvh，地址栏每次伸缩都会触发一次重排。在低端Android机上，这个重排如果发生在滚动过程里，可能出现肉眼可见的跳动。解决方案是把"需要稳定视觉"的元素（比如背景层）和"需要跟随内容"的元素区分开，前者用svh或lvh定死，后者用dvh跟随。

第二，100dvh不解决"安全区域"问题。iPhone的刘海屏、底部Home Indicator区域，属于viewport-fit=cover下的环境变量控制范畴，跟dvh是两条独立的技术线。100dvh给出的高度包含了安全区，如果你希望内容避开Home Indicator，还是得配合env(safe-area-inset-bottom)来处理：

.safe-bottom { height: calc(100dvh - env(safe-area-inset-bottom, 0px)); }

第三，也是我踩过的一个坑：当页面里有position: fixed的元素时，100dvh不总是等于"可视区域高度"。原因在于，fixed元素在某些浏览器里参照的是布局视口（layout viewport），而dvh是基于"小视口/大视口/动态视口"这些抽象层次计算的，两者在特定浏览器下的参照系不同，会出现offset。所以如果你写了height: 100dvh但发现fixed元素底部仍有一条缝隙，别急着怀疑语法，先看看是不是浏览器把fixed元素的包含块给"特殊对待"了。

4. 键盘弹出与视觉视口：最难处理的隐藏问题

4.1 layout viewport 与 visual viewport 的区别

如果你以为dvh能一路躺赢，那下面这个问题迟早会让你清醒：软键盘。

移动端浏览器的视口体系里有两个概念：布局视口（layout viewport）和视觉视口（visual viewport）。布局视口是页面布局所基于的坐标系，你可以把它理解成"浏览器觉得自己展示的是多宽多高的一块画布"；视觉视口是用户当前屏幕上真正能看到的那块区域，软键盘弹出来、页面缩放、地址栏伸缩，都会改变视觉视口的尺寸，但不一定会改变布局视口。

输入框聚焦、键盘弹出这个场景，恰恰是这两种视口分歧最大的时候。在旧版iOS Safari里，键盘弹出时window.innerHeight不变（因为它是布局视口的高度），CSSdvh在大多数情况下也不会跟着键盘走——因为键盘不是浏览器UI，它覆盖在页面上层，不影响视口单位定义。这就导致了大家最熟悉的那个bug：输入框聚焦后，页面底部的内容被键盘挡住，怎么滚都滚不出来。

4.2 一个可靠的交互层处理方案

针对这个场景，纯CSS是无解的，必须借助 JS 的visualViewportAPI。它提供visualViewport.height表示当前真正的可视高度，还提供resize事件和scroll事件来监听视觉视口的变化：

const visualViewport = window.visualViewport; function syncWithKeyboard() { const vh = visualViewport.height * 0.01; document.documentElement.style.setProperty('--visual-vh', `${vh}px`); // 可选：让当前聚焦元素滚到视觉视口可视范围内 } visualViewport.addEventListener('resize', syncWithKeyboard); visualViewport.addEventListener('scroll', syncWithKeyboard); syncWithKeyboard();

.fix-bottom-bar { /* 键盘未弹出时：跟随动态视口 */ height: calc(100dvh - 50px); /* 键盘弹出时：用视觉视口高度覆盖 */ height: calc(var(--visual-vh, 1dvh) * 100 - 50px); }

这段代码的思路是：默认状态下所有元素都走dvh或者自定义属性的CSS路径，而视觉视口API只在键盘弹出/收起时介入，用一个更高的优先级去修正底层高度。实际测试下来，在iOS 15+和Android Chrome 108+上，这个方案能覆盖绝大多数输入框被键盘遮挡的场景。

我之所以强调"交互层处理"，是因为这里的核心诉求不是"让页面高度等于键盘上方剩余高度"——这几乎不可能也不必要——而是"保证当前聚焦的输入框不被遮住，且用户能看到正在操作的内容"。有时与其纠结高度，不如在键盘弹出时把输入框scrollIntoView一下。

4.3 华为/小米等安卓定制ROM上的差异

聊几句国内的实际情况。Android原生浏览器的视觉视口行为相对统一，但华为、小米、vivo这些厂商的定制系统里，软键盘的"沉浸模式"各不相同。有些ROM默认会把页面整体上推（即windowSoftInputMode=adjustResize方式），视觉视口被压缩，visualViewport.height会变化，这种环境下上面的JS方案异常好用；另一些ROM选择键盘覆盖页面但不压缩布局（adjustNothing行为），视觉视口高度不变，那就需要主动把输入框scrollIntoView或者给固定底栏做平移。

做移动端H5开发，最忌讳的就是拿一台iPhone测完就以为万事大吉。我自己的习惯是真机矩阵里至少放三台：一台iPhone（最好带刘海）、一台小米/红米、一台华为或荣耀。每次改动视口相关逻辑，三个机器全部过一遍键盘弹出和滚动收起的场景，能少踩一大半环境差异的坑。

5. 生产环境中的最终方案：一套可以直接抄的写法

5.1 我的推荐组合

综合前面所有分析，我现在的新项目里，移动端满屏布局的标准写法是这样的：

:root { /* 默认走动态视口，回退到100vh */ --full-height: 100vh; --full-height: 100dvh; /* 键盘相关场景由JS更新 */ --visual-height: 100vh; --visual-height: 100dvh; } .full-screen { height: var(--full-height); } .fixed-toolbar { position: fixed; left: 0; right: 0; bottom: 0; height: calc(var(--full-height) - 100dvh + 56px); /* 上面这行属于特殊情况处理，一般直接用下面的写法更直观 */ } .safe-bottom { padding-bottom: env(safe-area-inset-bottom, 0px); }

别被上面那段唬住，我实际用得最多也是最朴素的组合是下面这样：

.page { min-height: 100vh; /* 老浏览器兜底 */ min-height: 100svh; /* 新浏览器优先用小视口，防止内容被遮 */ min-height: 100dvh; /* 支持动态视口的浏览器获得完美跟随 */ }

对绝大多数场景来说，这个三连声明就足够了。它把"安全"放在第一位——就算浏览器只认识第一个100vh，也不会出现大问题；认识svh的会优先用更保守的尺寸；认识dvh的则获得最佳体验。不需要JS，不需要监听事件，不会在滚动的瞬间闪烁。

需要JS介入的，只有软键盘场景。所以我的完整方案其实是：CSS三连声明打底，visualViewport事件兜底键盘场景，安全区用env()处理。三者各管一段，互不干扰。

5.2 真机验证中的几个案例

拿一个实际项目举例。一个移动端报名页面，结构是"顶部背景图 + 中间表单 + 底部提交按钮"。提交按钮用了position: fixed; bottom: 0，表单区用min-height: 100dvh。问题出现在点击手机号输入框时，键盘弹出，底部按钮被键盘顶到中间，视觉上像是"按钮漂移"。

用上面说的visualViewport方案处理之后，逻辑变成：键盘弹出时，给按钮容器加一个transform: translateY(-${键盘遮挡高度}px)，这个高度用visualViewport.height和window.innerHeight的差值算出来，等于键盘实际遮住的部分。实测在iOS和Android上都能精确贴合，而且因为是transform变化，不会引发布局回流，动画还算顺滑。

另一个案例是移动端瀑布流页面，文章卡片用了height: calc(100vh - 120px)来制造"首屏卡片正好露出一部分"的视差效果。在Android上，地址栏折叠之后，这个计算值偏大，首屏露出的部分比设计稿多。换成100svh之后，计算基准固定为最小可视高度，效果就稳定了——每次刷新、每个机型，露出的比例都一致。

这两个案例恰好说明前面那个判断：先明确语义，再选单位。报名页需要的是"跟随当前键盘状态"，所以用动态值；瀑布流卡片需要的是"初始态稳定一致",所以用小视口值。没有哪个单位是绝对最优，选对场景才是关键。

5.3 关于布局抖动和性能的几个提醒

dvh是动态值，这个动态特性是有代价的——浏览器在地址栏伸缩、键盘弹起这类变化发生时，需要重新计算依赖它的所有受影响的元素。如果你的页面里到处都是100dvh，而且每个都参与复杂布局，那么在低端机上可能会出现掉帧。

我的经验法则是：

1. 能用svh或lvh表达的场景，就不要上dvh。比如背景层、占位容器、跟内容不联动的装饰元素，定死一个值就好。
2. 只有"必须严格跟随当前可视区域"的元素（底部工具条、弹窗内容区、全屏滚动容器）才用dvh，并且尽量让这类元素少参与其他元素的布局计算。
3. 如果发现滚动时背景或弹层有明显跳变，先别急着换方案，打开Performance面板看看是不是dvh相关的样式重计算导致长任务——有时候只是某一条will-change: height加错了位置。

6. 从100vh延伸出去：移动端布局的另一种解题思路

6.1 当"铺满一屏"不依赖视口单位时

聊了这么多视口单位，我想换个角度多说一句：很多场景下，"铺满一屏"这个需求，其实根本不需要用视口单位来实现。

如果你用的是现代CSS布局，尤其是flex和grid，很多"满屏"的诉求可以被自然消化。拿最常见的"底部导航栏 + 内容区"来说，完全可以这样写：

.app-shell { display: flex; flex-direction: column; height: 100dvh; /* 或者svh/lvh，按语义选 */ } .content { flex: 1; /* 自动占据导航栏之外的所有剩余空间 */ overflow-y: auto; } .bottom-nav { flex-shrink: 0; /* 防止被压缩 */ height: 56px; }

在这个结构里，内容区的高度是"总高减去导航栏"之后动态算出来的，无论视口怎么变化，内容区都会自动跟着伸缩，不需要写任何calc()，也不存在"减去固定值后底部漏白"的问题。这才是移动端布局里真正重要的能力——不是精确控制每一毫米，而是让弹性布局替你消化不确定的浏览器行为。

同理，弹窗居中这种需求，用flex的align-items: center; justify-content: center加height: 100dvh一个容器就能搞定，完全不需要top: 50%; transform: translateY(-50%)那种老办法。

6.2 旧项目的渐进式改造建议

如果你手头是一个跑了多年的老项目，里面铺满了100vh，我不建议一口气全局替换成100dvh。原因很简单：老项目里可能存在大量依赖旧行为的"隐性约定"，比如某个容器故意用100vh撑出超出可视区域的高度来隐藏内容，或者某个组件的滚动计算依赖固定视口高度，全局替换会把这些隐性逻辑全部打乱。

我的做法是分三步走：

1. 先挑出视觉上问题最明显的几个页面，确认它们的语义（小视口/大视口/动态），按需加上对应的新单位，只影响局部。
2. 在新写的公共组件里直接用三连声明，逐步让新代码成为主流。
3. 等大部分页面完成改造后，再在根选择器或者全局样式里做一次残余清理，把裸的100vh降到最低。

这套渐进式策略，比"周末花一天全量替换"的风险要低得多。我见过不止一个项目因为手快全局替换，把隐藏导航、懒加载占位、滚动锚定之类的逻辑全打破了，最后花了两周收拾残局。

6.3 工具链和调试上的几个辅助手段

最后分享一些提高效率的工具层面的建议。

• Chrome DevTools的Device Toolbar里，可以手动模拟地址栏展开/收起两种状态，方法是点击顶部工具栏的三点菜单，选择"显示/隐藏设备工具栏"，然后在模式里选"响应式"并拖动高度。趁早发现视口变化时的布局问题，别等真机测试才暴露。
• Safari的Web Inspector在真机远程调试时很好用，特别是查看visualViewport的实时数值。连接iPhone后，选中某个元素，在右侧的"元素"面板里能看到它的视口尺寸信息。
• 如果你用VSCode，可以装一个CSS Units的扩展，它能高亮标记代码里的vh、dvh、svh、lvh，一目了然，避免团队里有人混用单位还不自知。
• 项目里的CSS规范文档中，建议明确写一条：新代码禁止单独使用100vh，必须配合svh/dvh的渐进增强写法。这个约定能省掉很多review时争论的时间。

我在实际项目中踩过最贵的一次坑，是在一个活动页里用了100vh当作弹窗遮罩层的高度，配合position: fixed使用。iPhone上地址栏展开时，遮罩底部漏出一条缝，用户能看到下层页面在滚动，以为是页面出了故障，投诉直接到了运营那里。那次之后，我把自己项目的全局搜索里所有的100vh都过了一遍，能换成dvh的都换了，不能换的至少确认了语义是"大视口"。从那以后，移动端视口相关的工单数量几乎降到了零。

视口单位的本质，是在跟浏览器的"动态UI"赛跑。跑赢了赛道的，是那些清楚自己项目语义、懂得在各种单位之间做取舍的人；而那些还在盲目复制代码的，大概率会继续在这条赛道上摔跟头。希望这篇内容能让你少摔几次。