应优先使用100dvh于需实时响应地址栏收放的场景（如轮播图外层、固定底栏父容器），但必须用min-height: 100vh兜底，并通过@supports (min-height: 100dvh)升级，避免iOS 15及微信/QQ WebView等不支持环境导致高度塌陷。
什么时候该用 100dvh 而不是 100vh
100dvh 适合需要**实时响应地址栏收放**的容器，比如轮播图外层、固定底栏的父容器、或需要“始终贴底不溢出”的交互区域。它在 Safari 16.4+、Chrome 109+ 等现代浏览器中能准确反映当前可视高度，但 iOS 15 及更早、微信 WebView、QQ 浏览器等环境完全不识别——直接写会丢弃整条声明，导致高度塌陷。
必须先兜底：min-height: 100vh，再用 @supports (min-height: 100dvh) 升级。注意：@supports 必须写成 min-height（不是 height），且不能合并检测多个单位。
- 错误写法：
@supports (min-height: 100dvh), (min-height: 100svh)→ 这是“与”逻辑，任一不支持就整个块失效 - 正确写法：分开两个
@supports块，各自独立生效 - Safari 16.4–17.2 存在首屏闪动风险：地址栏状态未稳定时，
100dvh可能短暂取错值，建议配合 JS 节流重设
100svh 和 100lvh 不是 dvh 的降级选项
100svh 和 100lvh 语义完全不同，混用会导致布局错位。它们不是“更小/更大的 dvh”，而是三个独立计算逻辑：
-
100svh= 地址栏**强制显示时**的最小可用高度，适合支付页底部按钮、确认弹窗等“绝不能被遮挡”的元素 -
100lvh= 地址栏**强制隐藏时**的最大可用高度，适合全屏视频、Canvas 绘图，但滚动初期顶部可能被地址栏盖住 -
100dvh= 当前**实时可视区域高度**，适合轮播图、可滚动内容区等需动态响应的场景
例如，给输入框父容器设 min-height: 100svh + display: flex + margin-top: auto，键盘弹出时容器自动收缩，输入框仍可见；但若误用 100dvh，安卓上可能因 WebView 不支持而回退到 100vh，失去响应能力。
立即学习“前端免费学习笔记（深入）”；
微信/QQ 等 WebView 环境下必须 JS fallback
截至 2026 年 8 月，微信内置 WebView、QQ 浏览器仍未透出 dvh/svh/lvh 支持，哪怕底层 Chromium 版本足够新。CSS @supports 检测会失败，纯 CSS 方案不可靠。
稳妥做法是监听 window.resize，节流后读取 window.innerHeight，并结合 document.documentElement.clientHeight 做兜底判断：
- 避免高频触发：用
requestAnimationFrame或 100ms 节流 - 区分键盘弹出：iOS 上
innerHeight明显变小（通常 ≤ 400px）可视为键盘展开；安卓需额外监听focus/blur配合延时判断 - 不要依赖
env(keyboard-inset-bottom)：iOS 16.4+ 才支持，安卓不支持，且仅在键盘弹出时有值
三者共存时的兼容写法要点
一个页面同时用到 100dvh、100svh、100lvh 是常见需求，但必须按单位分别处理：
- 每个单位单独写
@supports块，不能合并条件 - 所有使用处都必须有
100vh或100%兜底，否则不支持环境直接失效 -
svh和lvh在部分安卓定制壳中行为不稳定，建议只用于 iOS 主要场景，安卓端优先用 JS 动态 height - 测试真机环境比模拟器更重要：iOS 15 实机、微信 8.0.x、QQ 浏览器 12.x 都需覆盖
真正麻烦的不是语法，而是不同 WebView 对同一标准的实现割裂——dvh 在 Safari 里跑得稳，在微信里根本不存在，这种差异必须靠分层 fallback 来弥合，而不是寄希望于某一条 CSS 规则通吃。
