如何用vh单位打造真正响应式的 CSS Grid 布局？

你有没有遇到过这种情况：在桌面浏览器上调试得好好的全屏布局，一到手机上就“多出一截”，页面莫名其妙地出现滚动条？或者明明写了height: 100vh，可内容区域就是撑不满屏幕？

这背后的问题，往往不是代码写错了，而是我们对CSS Grid 与vh单位的结合使用理解得还不够透。

别急——今天我们就来彻底搞清楚：如何让 CSS Grid 真正“贴满”视口，并且在各种设备上都表现一致。这不是简单的属性堆砌，而是一套完整的布局思维升级。

从一个常见需求说起：我想做一个“头部固定 + 内容滚动 + 底部贴底”的页面

这种结构太常见了：比如后台管理系统、移动端单页应用、登录页、仪表盘……它们都有一个共性：

页面整体占满整个屏幕，但只有中间部分可以滚动，头尾始终固定。

听起来很简单？可一旦动手就会发现，传统方式要么依赖 JavaScript 计算高度，要么在不同设备上错位严重。

而现代 CSS 的解法其实非常优雅：用display: grid搭骨架，用vh定基准，再配合fr实现弹性填充。

.app { display: grid; height: 100vh; grid-template-rows: 60px 1fr 50px; /* 固定头、弹性体、固定尾 */ grid-template-areas: "header" "main" "footer"; }

就这么几行 CSS，就已经解决了过去需要 JS 才能完成的高度分配问题。

但等等——为什么有时候它还是不工作？尤其是在 iPhone 上？

别急，我们先搞明白两个核心角色：vh和 Grid 到底是怎么协作的。

vh不是“屏幕高”，它是“当前可见区”的 1%

vh是 viewport height 的缩写，字面意思是“视口高度的 1%”。
所以100vh = 当前可视区域高度 × 100%。

关键在于：“可视区域”到底是谁说的算？

桌面端很听话，移动端却爱演戏

在 Chrome 桌面上，100vh就是你窗口的高度，稳得很。

但在 iOS Safari 上呢？当你打开网页时，地址栏是显示的，此时100vh包含了地址栏和工具栏的高度；等你开始滑动页面，这些 UI 隐藏后，实际可见区域变大了，但vh值没变！结果就是：

页面看起来被“压扁”了，底部留白，或者根本没法滚动到底。

这就是为什么很多人吐槽：“100vh在手机上不准”。

但这不是 bug，是设计如此。浏览器把vh锁死在初始视口，而不是动态调整。

那怎么办？三种实战方案任你选

✅ 方案一：用dvh—— 动态视口单位（推荐）

现代 CSS 已经推出了新的单位：dvh（dynamic viewport height），它会根据浏览器 UI 的展开/收起自动调整。

.app { height: 100dvh; /* 自动适应 Safari 地址栏变化 */ }

一行代码搞定，干净利落。

兼容性提醒：
- Chrome 76+
- Safari 15.4+（iOS 15.4）
- Firefox 尚未完全支持（可通过特性检测降级）

✅ 方案二：运行时注入真实vh（兼容老版本）

如果你必须支持更老的设备，可以用 JS 动态设置变量：

function setVH() { const vh = window.innerHeight / 100; document.documentElement.style.setProperty('--vh', `${vh}px`); } // 初始化 + 监听 resize setVH(); window.addEventListener('resize', setVH);

然后在 CSS 中这样用：

.app { height: calc(100 * var(--vh)); /* 相当于 100vh */ }

虽然多了点 JS，但胜在稳定可靠，适合生产环境兜底。

❌ 不推荐方案：用100%替代vh

有些人图省事，直接写height: 100%。但记住：百分比高度依赖父元素明确设高。如果html或body没有设高，这个100%就是无效的！

正确的做法永远是从根节点传递高度：

html, body { height: 100%; margin: 0; padding: 0; }

否则别说100%，就算你写9999px都可能失效。

Grid 布局不只是“分格子”，它是布局引擎

很多人以为 Grid 就是“画表格”，其实它更像是一个布局操作系统：你可以定义坐标系、命名区域、控制伸缩行为。

让我们看个典型后台布局：

.layout { display: grid; height: 100dvh; grid-template-columns: 240px 1fr; grid-template-rows: 60px 1fr 60px; grid-template-areas: "sidebar header" "sidebar main" "sidebar footer"; gap: 1px; background: #ddd; }

对应的 HTML：

<div class="layout"> <div class="sidebar">导航</div> <div class="header">顶部栏</div> <div class="main">内容区</div> <div class="footer">版权信息</div> </div>

这个布局强在哪？

• 左侧边栏固定宽240px，右侧主内容自动拉伸；
• 头部和底部固定高，中间main使用1fr吃掉所有剩余空间；
• 所有区域通过grid-area明确定位，不怕 DOM 顺序影响；
• 整体高度基于动态视口，移动端也不会溢出。

而且你会发现：不需要任何 JavaScript，也不需要媒体查询，就已经是一个基本可用的响应式结构了。

为什么fr是vh最好的搭档？

在 Grid 中，fr单位代表“自由空间的一部分”。它和vh配合，简直是天作之合。

举个例子：

grid-template-rows: 80px 1fr auto;

这句话的意思是：
- 第一行：固定 80px（比如头部）
- 第二行：拿走剩下的所有空间（主体内容）
- 第三行：根据内容自适应（比如页脚）

注意：这里的“剩下空间”就是100vh - 80px - footerHeight，由 Grid 自动计算。

这意味着：无论屏幕是 600px 还是 1000px 高，中间区域都能完美填满，不会有空隙或溢出。

相比之下，如果你用height: calc(100vh - 130px)给 main 设定高度，不仅难维护，还会因为 footer 高度不确定而出错。

所以记住一句话：

固定部分用px或vh，弹性部分交给1fr，这才是现代布局的正确姿势。

开发中那些容易踩的坑，我都替你试过了

🔹 坑点1：Grid 子元素没撑满，是因为忘了传高度

最常见的问题是：.app-grid明明设了100vh，但里面的<main>就是不高。

原因往往是这一句漏了：

html, body { height: 100%; }

没有这句，body的高度默认是“内容决定”，哪怕你.app-grid想占满，也没法继承。

🔹 坑点2：用了vh，但动画卡顿

不要在频繁动画中直接使用vh。因为每次视口变化（比如旋转屏幕），都会触发重排重绘，性能开销大。

建议：
- 静态布局用vh完全没问题；
- 动画场景改用rem、em或transform移动；
- 必须用时，加will-change: transform提升图层。

🔹 坑点3：移动端键盘弹起导致布局崩溃

当输入框聚焦，软键盘弹出时，视口高度剧减，100vh也会跟着缩水，可能导致按钮被顶上去、表单遮挡。

解决方案：
- 对关键操作区域使用min-height而非height；
- 或监听focus/blur事件临时调整布局；
- 更高级的做法是检测visualViewport变化。

最佳实践清单：写出健壮的 Grid + vh 布局

写在最后：未来的视口单位会更智能

dvh只是个开始。W3C 正在推进更多精细化视口单位：

• svh: small viewport height（最小可视高度）
• lvh: large viewport height（最大可视高度）
• bsvh: block-axis small viewport height（按方向区分）

未来我们可以这样写：

.modal { height: 80lvh; /* 全屏时用大高度 */ }

根据不同设备状态自动选择最合适的基准，真正做到“情境感知”的布局。

如果你正在构建 PWA、移动端 H5、管理后台或全屏交互页面，那么vh+ Grid的组合绝对值得你深入掌握。

它不仅能帮你摆脱 JavaScript 布局计算的泥潭，还能让你的界面在各种设备上都保持优雅一致。

下次当你又想用 JS 获取window.innerHeight来设高时，不妨停下来问问自己：

“我是不是可以用100dvh+1fr一行 CSS 解决？”

试试看，你会爱上这种“声明式布局”的简洁之美。

你在项目中用过vh和 Grid 吗？遇到了哪些奇怪问题？欢迎留言分享你的经验！