最可靠解法是用 @supports 包裹整条 min-height: 100dvh 规则并外置 min-height: 100vh 降级，因 iOS Safari 15.x 及微信 WebView 不支持 dvh，需 JS 动态设 --vh 并监听 resize 防抖。
直接用 min-height: 100dvh 并配 @supports 降级，是当前最轻量、最可靠的解法；但裸写或写错包裹方式，反而会让新旧 Safari 都失效。
为什么必须用 @supports 包裹整条 100dvh 规则
iOS Safari 16.4+ 和 Chrome 105+ 才原生支持 100dvh，旧版（尤其是 iOS 15.x 及微信 WebView）会直接忽略该声明。如果只写：
.page {<br> min-height: 100vh;<br> min-height: 100dvh; /* 错误：老 Safari 忽略这行，新 Safari 仍用上一行 */<br>}结果是所有 Safari 都走 100vh，问题照旧。
-
@supports必须包裹整个 CSS 规则块，不能只包值 - 兜底声明（
min-height: 100vh）必须写在@supports外面，确保老环境至少有基础高度 - 优先用
min-height而非height，避免内容超长时被截断
position: absolute 元素套 100dvh 为啥没反应
绝对定位元素的百分比高度（包括 100dvh）依赖包含块（containing block）的高度，不是“强制占满屏幕”。常见于弹窗、遮罩层、底部固定按钮。
立即学习“前端免费学习笔记（深入）”；
- 父容器（如
body或直接祖先）没设min-height: 100dvh或显式高度 → 子元素100dvh实际计算为 0 - 别对绝对定位元素用
height: 100dvh，改用top: 0; bottom: 0;更可靠 - 若父容器本身也靠
--vh驱动，需确保它先完成初始化，否则子元素读到的是初始 1px
兼容 iOS 15 及微信 WebView 必须用 JS 动态设 --vh
微信内置浏览器、QQ 浏览器、iOS 15.x 等环境根本不认 dvh 或 svh，CSS 方案在此类场景下完全失效。此时唯一可靠路径是监听 resize（不是 scroll）。
- 必须在
DOMContentLoaded后立即执行一次，否则首屏渲染用的是地址栏未收起时的错误初始值 - 防抖必须用
requestAnimationFrame，而非setTimeout：微信安卓下resize触发极快且无规律，节流不当会导致高度卡死 - CSS 中统一用
min-height: calc(var(--vh, 1px) * 100)，不依赖父容器是否设了height: 100% - 别漏掉安全区：微信 iOS 底部「小白条」、Android 全面屏手势区，需用
padding-bottom: env(safe-area-inset-bottom)预留空间
别碰 -webkit-fill-available 和 100svh
-webkit-fill-available 是 WebKit 为 <input> 等表单控件设计的内部填充逻辑，不是通用高度单位；100svh 表示“工具栏都完全展开时的最小可视高度”，它不响应滚动变化，强行替换会导致滚动后底部大面积留白或内容上浮。
-
height: -webkit-fill-available在 iOS Safari 上支持极不稳定，某些版本退化为auto -
100svh在 Safari 直到 v17.4 仍不支持，写了就忽略 -
@supports (height: 100svh)做降级无效：Safari 不识别，整条规则失效 - 想撑满当前屏幕？用
100dvh，不是100svh
真正麻烦的不是写法本身，而是不同设备和内核对同一份 CSS 的解释差异——比如 iOS 15.7 和 iOS 16.4 对 @supports 的解析行为就不一致；微信安卓 X5 内核甚至会把 100dvh 当作无效值跳过，却不触发 fallback。这些细节不踩一遍坑很难意识到。
