100vh不等于视口可用高度，因其基于初始视口且包含浏览器ui；可靠方案是html/body设height:100%，容器用display:flex+height:100%，子项用flex:1分配空间，并在ios中结合env(safe-area-inset-bottom)降级处理。
height: 100vh 不等于“占满视口可用高度”
很多人写 height: 100vh 是为了撑满屏幕，结果发现顶部有滚动条、底部被截断，或者在 iOS Safari 里突然变矮——这是因为 100vh 指的是「初始视口高度」，不随地址栏收起/弹出动态调整，且会把浏览器 UI 高度（比如 Chrome 的底部导航栏）也算进去。真要“弹性撑满”，光靠 100vh 不够稳。
- 移动端 Safari 中，地址栏收起时
100vh不更新，导致内容被遮挡或留白 - 桌面端 Chrome 在缩放或分屏时，
100vh可能略大于实际可视区域，触发意外滚动条 - 如果父元素没设高度（比如
body缺少height: 100%），100vh虽然生效，但内部flex子项的flex: 1可能失效
display: flex + height: 100% 才是可靠组合
想让容器真正“弹性撑高”，关键不是只设 100vh，而是打通从根到目标容器的高度链，并用 flex 分配剩余空间。常见错误是只在目标容器上写 display: flex; height: 100vh，却忘了 html 和 body 默认没有高度。
-
html和body必须显式设height: 100%，否则height: 100%在子元素上无意义 - 目标容器设
display: flex; flex-direction: column;，再用flex: 1让某个子区占满剩余空间 - 避免对 flex 容器本身再设
min-height: 100vh—— 这会破坏弹性，导致内容超长时无法自然滚动
示例结构：
html, body {
height: 100%;
margin: 0;
}
.container {
display: flex;
flex-direction: column;
height: 100%;
}
.header { height: 60px; }
.main { flex: 1; overflow-y: auto; }
.footer { height: 40px; }
iOS Safari 下的 viewport-fit 和 env() 补救方案
iOS Safari 对 100vh 的处理最不稳定，尤其在地址栏隐藏后。此时需配合 viewport-fit=cover 和 CSS 环境变量 env(safe-area-inset-bottom) 做微调，但注意：这不是替代 flex 的方案，而是兜底。
- 在
<meta>中加viewport-fit=cover，让页面渲染区覆盖整个物理屏幕 - 用
height: calc(100vh - env(safe-area-inset-bottom))替代纯100vh，避免底部被 iPhone 拖拽条遮住 - 这个
env()只在支持 safe area 的设备上生效，老浏览器会忽略，所以必须搭配降级（如 fallback 为100vh）
flex: 1 和 min-height: 100vh 别混用
有人为了“至少全屏、又能自适应”，给容器同时写 flex: 1 和 min-height: 100vh，结果发现 flex 失效或滚动异常。根本原因是：当容器有 min-height，且其父容器高度未严格限定（比如只靠 100vh），flex 的“剩余空间计算”就会失准。
- 优先选
height: 100%+flex组合，它天然支持内容溢出滚动 - 除非明确需要“最小撑满 + 内容超出仍可滚动”，才考虑
min-height: 100vh，但此时别再套flex: 1，改用flex-direction: column+flex: 1在子元素上 - 调试时用浏览器 devtools 检查 computed height，确认是否真被父级约束住——很多问题其实卡在
html或body少写了height: 100%
实际项目里最容易被跳过的，是 html 和 body 的高度声明，以及 iOS 上 env() 的 fallback 处理。这两处一漏，flex 布局就容易在特定设备上“看起来没问题”，上线后突然崩。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
