直接用100dvh会失效是因为旧环境不识别该单位导致CSS声明被跳过，必须用@supports包裹整个选择器块进行降级，且坚持用min-height而非height；绝对定位元素需确保父容器有高度或改用top:0;bottom:0；svh/lvh适用于特定场景，JS动态设--vh变量是必要兜底。
为什么直接用 100dvh 会塌掉或不生效
不是浏览器不支持，而是写法错了。很多开发者把 min-height: 100vh 直接替换成 min-height: 100dvh 就以为万事大吉，结果在 iOS 15 或微信 X5 内核里页面“塌”成一行——因为这些环境压根不认识 100dvh，CSS 解析失败后直接跳过整条声明，退回到无高度状态。
@supports 不是可选项，是强制要求：必须包裹整个选择器块，不能只包值；也不能写成 min-height: 100vh; min-height: 100dvh; 这种叠加写法，否则新 Safari 仍走 100vh 老路。
- 错误写法：
.page { min-height: 100vh; min-height: 100dvh; } - 正确写法：
.page { min-height: 100vh; } @supports (min-height: 100dvh) { .page { min-height: 100dvh; } } - 别用
height，坚持用min-height：内容超长时不会被裁剪，用户能正常滚动到底部
100dvh 在绝对定位元素里为啥还是没占满屏幕
根本原因不是单位失效，而是包含块（containing block）没给足上下文。如果你给一个 position: absolute 元素设了 min-height: 100dvh，但它的父容器只是 position: relative 且没设任何高度，那这个 100dvh 实际计算的是最近那个有高度的祖先，而不是屏幕。
这时候 top: 0; bottom: 0; 比 min-height: 100dvh 更可靠——它不依赖父容器高度，只要父容器是 relative 或 fixed，就能撑满当前可视区域。
立即学习“前端免费学习笔记（深入）”；
- 优先检查父容器是否设置了
min-height: 100dvh或显式height - 若无法控制父容器高度，改用
top: 0; bottom: 0;+position: absolute -
-webkit-fill-available别乱用：对min-height无效，软键盘弹出时不响应，iPad Chrome 中甚至导致高度翻倍
什么时候该用 100svh 或 100lvh，而不是 100dvh
100dvh 是“当前可见视口”，但它不是万能解药。比如登录页底部有输入框，你希望键盘弹出时内容不被顶飞，这时 100dvh 会随键盘收起而变高，反而加剧错位；而 100svh（small viewport height）始终按工具栏展开时的最小视口算，更稳定。
目前支持情况：iOS 16.4+、Chrome 109+、Firefox 110+、Edge 110+ 已支持 dvh；svh 和 lvh 支持略窄，尤其安卓 WebView 表现不一，线上项目建议只在明确目标环境时谨慎使用。
-
100svh：适合固定布局、需避免键盘干扰的场景（如全屏表单） -
100lvh：适合地址栏常隐藏、追求最大可用空间的 PWA - 别混用：
height: 100vh; height: 100svh; height: 100dvh;这种堆叠会让旧浏览器取第一个，新浏览器可能取最后一个，但行为不可控
JS 动态设 --vh 变量仍是必要兜底
哪怕你写了完整的 @supports 降级，遇到 iOS 15、某些安卓 WebView 或微信内置浏览器，100dvh 依然可能被忽略或计算异常。这时候 JS 获取 window.visualViewport?.height 并设置 CSS 变量，是目前唯一能精确响应滚动、键盘、横竖屏三重变化的方案。
注意监听点不止 resize：iOS 上 visualviewport.resize 才真正反映地址栏收放；软键盘弹出时，resize 可能不触发，得靠 focusin/focusout 配合判断。
- 关键监听：
visualviewport?.addEventListener('resize', handler)，比window.addEventListener('resize')更精准 - 初始化必须做：页面加载完立刻执行一次，否则首屏就错
- CSS 中统一用
calc(var(--vh, 1vh) * 100)，确保变量未定义时有 fallback
真实项目里最麻烦的从来不是写对 100dvh，而是父容器高度缺失、绝对定位上下文断裂、以及老 WebView 对 @supports 的解析差异——这些地方一漏，整个“铺满一屏”的逻辑就断在看不见的地方。
