最可靠解法是先兜底min-height: 100vh，再用@supports (min-height: 100dvh)包裹升级规则；iOS 15及更早、微信/QQ等WebView不识别dvh会丢弃声明，必须JS动态设--vh变量并监听resize防抖。
直接用 100dvh 会炸，必须加 @supports 检测
iOS 15 及更早版本、微信内置 WebView（截至 2026 年 5 月）、QQ 浏览器等环境压根不认识 dvh。CSS 解析器遇到非法单位会直接丢弃整条声明，比如写 min-height: 100dvh，旧环境里这个属性就没了，退回到无高度控制状态。
正确写法是先兜底 100vh，再用 @supports 升级：
.full-height {
min-height: 100vh;
}
@supports (min-height: 100dvh) {
.full-height {
min-height: 100dvh;
}
}-
@supports必须精确匹配语法：(min-height: 100dvh)有效，(height: 100dvh)无效（height不支持dvh） - 别写
@supports (dvh: 1px)——这不是合法检测方式，浏览器会忽略 - 首次渲染时 Safari 16.4–17.2 可能因内部时机问题导致闪动，
@supports本身不解决这个，需配合 JS 节流或延迟应用
svh 和 dvh 完全不是一回事，混用必错
看到 100svh 就以为是“更小的 dvh”？错。它们语义隔离，计算逻辑和适用场景完全不同：
-
100svh= 地址栏**强制显示时**的最小可用高度，适合支付页底部按钮、弹窗确认区——确保永远不被遮挡 -
100dvh= 当前**实时可视区域高度**，适合轮播图容器、固定底栏——滚动时自动响应 - 在同一个组件里同时写
height: 100dvh和padding-bottom: 10svh，数值基准不同，结果不可预测，布局大概率错乱
如果要用 svh，也得单独做 @supports 检测：@supports (min-height: 100svh)，不能和 dvh 共用一套检测逻辑。
立即学习“前端免费学习笔记（深入）”；
监听 scroll 根本不管用，iOS 地址栏显隐触发的是 resize
很多人试图靠监听 scroll 来手动更新高度，结果发现滞后甚至完全不更新——因为 iOS Safari 地址栏收起/展开时，触发的是 resize 事件，不是 scroll。
JS fallback 的关键点：
- 在
DOMContentLoaded后立即执行一次：document.documentElement.style.setProperty('--vh', `${window.innerHeight * 0.01}px`) - 监听
resize，并加 300ms 节流（iOS 连续resize高频） - CSS 中必须用
calc(var(--vh, 1vh) * 100)，避免变量未定义时整个计算式失效 - 不要在
scroll里反复读取window.innerHeight，性能差且不准
微信 WebView 等壳浏览器必须 JS fallback
dvh 在 iOS Safari 16.4+、Chrome 109+、Edge 109+ 支持良好，但微信、QQ、钉钉等国产壳浏览器至今未透出支持（2026 年 5 月数据仍如此）。这意味着仅靠 CSS @supports + dvh 是不够的。
真正跨平台稳定的方案只有一条路：JS 动态注入 --vh 变量，并用 calc(var(--vh, 1vh) * 100) 替代所有 100vh / 100dvh 场景。
复杂点在于：你得判断是否真需要 JS 方案——如果用户大量使用微信，那 CSS-only 就是假稳定；而如果只跑在现代 Safari 或 Chrome PWA 里，@supports + dvh 已足够干净。
