应优先使用100dvh，辅以env(safe-area-inset-bottom)预留底部安全区，并通过focus/blur事件动态切换body类来兜底；三者结合可兼顾兼容性、稳定性和用户体验。
移动端键盘弹出时 vh 失效怎么办
iOS 和部分 Android 浏览器在虚拟键盘弹出后会“假性缩放”视口，导致 100vh 变成键盘未弹出前的视口高度（即实际显示区域变小，但 vh 值不变），页面底部被键盘盖住或留白异常。
这不是 CSS bug，而是浏览器对「视觉视口」和「布局视口」分离的实现差异。直接靠 vh 做全屏容器，在键盘弹起后必然错位。
- Android Chrome 一般仍按物理屏幕高度计算
vh，表现相对稳定；iOS Safari 则几乎总是用初始视口高度，键盘一顶就露底 -
100vh在position: fixed或height: 100vh的弹层里尤其容易穿帮 - 别试图用
window.innerHeight+resize监听动态设style.height—— iOS 键盘收起时触发延迟、抖动严重，且 resize 在键盘弹出时不一定会触发
用 env(safe-area-inset-bottom) 适配键盘与刘海
env(safe-area-inset-bottom) 是更可靠的运行时变量，它在键盘弹出时会动态增大（iOS 16+ 支持良好，Android Chrome 106+ 也支持），可用于“预留底部安全区”，避免内容被遮挡。
但它不是键盘高度本身，而是系统 UI（包括键盘）侵入视口的最小距离，值随键盘状态变化，比硬写 calc(100vh - 400px) 更健壮。
立即学习“前端免费学习笔记（深入）”；
- 只在需要“贴底但不被盖”的场景用，比如输入框上方的滚动列表、底部操作栏
- 配合
padding-bottom: env(safe-area-inset-bottom)比height更安全，不会破坏文档流 - 必须加降级：
padding-bottom: max( env(safe-area-inset-bottom), 20px )，否则老版本 Safari 会忽略整条规则 - 注意：这个值在无键盘时是 0（非刘海/圆角设备），有键盘时才非零 —— 所以它天然适合“键盘感知”布局
监听 focus / blur 动态切换高度策略
纯 CSS 没法判断键盘是否弹出，但输入框聚焦是键盘弹出最确定的信号。用 JS 配合 class 切换，是最可控的兜底方案。
关键不是“监听键盘”，而是“信任 focus 事件”—— 它比 resize 或 scroll 更准时、更少误判。
- 给
input、textarea统一加focus监听，添加keyboard-open类到body - CSS 中写：
.keyboard-open .full-height { height: 100dvh; }（优先用dvh，见下一条） - 务必在
blur后加setTimeout(..., 100)再移除 class —— iOS 键盘收起动画结束比 blur 晚，否则闪一下 - 避免对每个输入框单独处理高度，统一用 body class 控制根容器，减少重排
优先用 dvh 替代 vh，但注意兼容性底线
100dvh（dynamic viewport height）是专门解决这个问题的新单位，它始终反映当前可见视口高度，键盘弹出时自动缩小，iOS 16.4+ 和 Chrome 108+ 已支持。
但它不是万能药：旧机型、微信内置浏览器（X5 内核）、QQ 浏览器等仍不支持，需 fallback。
- 写法必须是：
height: 100dvh; height: 100vh;（后者会被前者覆盖，但老浏览器只认vh） - 不要只写
100dvh，也不要用@supports (height: 100dvh)包裹整套样式 —— X5 等内核连 @supports 都不认 -
dvh在键盘收起后仍有短暂延迟（约 1–2 帧），若页面有 translateY 动画，可能轻微错帧，此时用focus/blurclass 更稳 - 目前最务实组合：
100dvh主力 +env(safe-area-inset-bottom)辅助 +focusclass 终极兜底
真正麻烦的从来不是“怎么让高度变小”，而是“怎么让变小的过程不闪、不跳、不卡”。三个手段混用不是过度设计，是应对不同内核的现实妥协。别漏掉 blur 后的延时清理，那是 iOS 上最容易白屏的一环。
