svh、dvh、lvh 是为解决移动浏览器中 100vh 不随地址栏收展动态更新而引入的现代视口单位：svh 取最小高度（地址栏展开时），dvh 取当前实时可用高度，lvh 取最大高度（地址栏收起时），三者关系恒为 svh ≤ dvh ≤ lvh。
svh、dvh、lvh 是为解决传统 vh 在移动浏览器中“不动态更新”问题而生的现代视口单位。它们不是语法糖，而是针对不同滚动/地址栏状态下的真实可用高度做了语义化区分——直接用 100vh 在 iOS Safari 里做全屏模块，页面会跳、内容被裁、用户滑动后留白，根本原因就是 vh 锁死在初始渲染时的视口高度，没随地址栏收起/展开重算。
为什么 vh 在手机上经常“不准”
iOS Safari 和部分 Android 浏览器中，vh 基于的是「初始视口高度」，即页面加载那一刻的 document.documentElement.clientHeight。但用户下拉收起地址栏后，可用视口变高，vh 却不会自动放大；反之，上拉展开地址栏，可用高度变小，vh 也不收缩。结果就是：height: 100vh 的元素在滚动后顶部/底部出现空白或溢出。
- 典型现象：页面刚打开时正常，一滚动就“错位”，尤其在
position: fixed+100vh的遮罩层上特别明显 - 触发条件：Safari 地址栏动画、Chrome 移动端地址栏隐藏/显示、PWA 全屏模式切换
- 本质是 CSS 层面无感知的布局断层，JS 也拿不到实时变化事件，只能靠新单位兜底
svh/dvh/lvh 各自对应什么场景
这三个单位都来自 CSS Viewport Units Level 2 规范，2023 年起在主流浏览器（Chrome 105+、Safari 16.4+、Firefox 114+）稳定支持，区别在于它们锚定的“视口类型”不同：
-
svh（small viewport height）：始终取「最小可能视口高度」，即地址栏完全展开时的高度。适合需要绝对不溢出、宁可留白也不遮挡内容的场景，比如弹窗容器、表单页最外层 wrapper -
dvh（dynamic viewport height）：取「当前实际可用高度」，地址栏收起时值变大，展开时变小，实时响应。这是目前最推荐用于全屏布局的单位，例如main { height: 100dvh; } -
lvh（large viewport height）：取「最大可能视口高度」，即地址栏完全收起时的高度。适合必须撑满、允许轻微滚动的场景，比如背景图、视频封面
三者数值关系恒为：svh ≤ dvh ≤ lvh。横竖屏切换时它们也会各自重算，无需额外 JS。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
怎么安全降级到老浏览器
IE 和旧版 Safari 不支持这三者，@supports 是唯一可靠检测方式。不要用 UA 判断，也不要 fallback 到 100vh——那等于回到原点。
- 写法必须带括号：
@supports (height: 100dvh)，不能省略单位 - 降级方案优先选
100%或flex: 1，配合明确的父容器height: 100vh或min-height: 100vh - 避免在
@supports外层再套媒体查询，CSS 解析顺序可能导致样式未生效
main {
height: 100%;
}
@supports (height: 100dvh) {
main {
height: 100dvh;
}
}和 vmin/vmax 混用要注意什么
dvh 可以和 vmin 一起用，但逻辑不是叠加，而是取两者计算后的最终值。例如 font-size: 4vmin 在横屏时按高度算，font-size: 4dvh 则永远按当前可用高度算——后者更稳，但前者能防横屏文字过大。
- 慎用
calc(100dvh - 60px)：如果 60px 是固定导航栏，它本身可能随地址栏收起而“上浮”，导致减法结果偏大，建议改用 Flex 布局 +flex: 1 -
dvh在嵌套iframe中行为未标准化，若页面嵌在第三方平台（如微信 WebView），优先测实机，别依赖理论值 - 服务端渲染（SSR）场景下，
dvh无法在 HTML 首屏直出时生效，需确保首屏关键内容不强依赖它，或加 loading 占位
真正难的不是记住三个缩写，而是理解它们背后代表的三种“真实高度”——设计稿里画不出这个差异，Figma 插件也模拟不了地址栏动画，只有真机连着 devtools 实时看 getComputedStyle 才信得过。
