lvh/svh 是 CSS 新增视口单位，lvh 表示不考虑软键盘的最大可用高度，svh 表示键盘弹出时的最小可用高度；相比 100vh，它们原生响应键盘状态，避免 iOS 底部 fixed 元素被遮挡及安卓高度突变问题。
lvh/svh 是什么，为什么比 100vh 更可靠
lvh（large viewport height）和 svh（small viewport height）是 CSS 新增的视口单位，2023 年起在 Safari 16.4+、Chrome 109+、Edge 109+ 中稳定支持。它们分别代表「不考虑软键盘时的最大可用高度」和「软键盘弹出时的最小可用高度」。相比 100vh，lvh 始终等于设备物理屏幕高度（iOS/Android 都稳定），而 svh 在键盘弹出时会自动收缩——这正是我们真正需要的响应信号。
用 100vh 做全屏容器高度，在 iOS 上键盘弹出时页面不会压缩，但 100vh 值不变，导致底部 fixed 元素被盖住；在安卓上它又可能突变，行为不可控。而 svh 是浏览器原生识别键盘状态后计算出的高度，无需 JS 推断，也不依赖 unreliable 的 window.innerHeight 变化。
如何用 lvh/svh 替代 100vh 布局
直接替换旧写法即可生效，但要注意适用范围和 fallback：
- 全屏页容器：把
height: 100vh改成height: 100lvh，确保初始渲染不被截断 - 可滚动内容区：用
max-height: 100svh限制最大高度，配合overflow-y: auto，让内容在键盘弹出时自然收缩留出空间 - 输入框父容器：设
min-height: 100svh+display: flex; flex-direction: column，再让输入框用margin-top: auto推到底部，键盘弹出时容器自动“收腰”，输入框仍可见 - 必须加降级：用
@supports not (height: 100lvh) { ... }回退到100vh或 JS 动态补 height
lvh/svh 与 env(keyboard-inset-bottom) 搭配使用
env(keyboard-inset-bottom) 提供键盘高度值（iOS 16.4+），但它只在键盘弹出时有效，且安卓不支持；svh 虽然能反映高度变化，但不直接给出像素值。两者互补：
立即学习“前端免费学习笔记（深入）”；
- 按钮上浮：用
bottom: env(keyboard-inset-bottom, 0px)+position: fixed，同时加@supports (bottom: env(keyboard-inset-bottom)) { bottom: calc(0px + env(keyboard-inset-bottom)); }避免解析失败 - 动态 padding：在 focus 时给容器加
padding-bottom: env(keyboard-inset-bottom, 250px)，但仅限 iOS；安卓需 fallback 到 JS 估算（如监听focus后延时读visualViewport.height差值） - 不要混用
svh和env(keyboard-inset-bottom)计算同一尺寸——svh是高度，env()是偏移量，语义不同，强行相减易出错
容易忽略的兼容性与调试陷阱
看似新特性很“干净”，但实际落地有三处硬伤：
- iOS 微信内置浏览器（X5 内核）至今不支持
lvh/svh和env(keyboard-inset-bottom)，哪怕 iOS 系统是 17.x —— 必须用 UA 判断并走 JS 分支 -
svh在页面刚加载、键盘尚未触发过时，值等于lvh；首次弹出键盘后才开始变化，所以不能靠它做初始布局判断 - Chrome Android 对
svh的更新有约 100ms 延迟，若在input.focus立即读取getComputedStyle(el).height，可能拿到旧值；应结合setTimeout(..., 120)或监听focusin后的scroll事件兜底
最稳妥的做法不是全押注新单位，而是用 lvh 做基础高度锚点，svh 控制可滚动区域，env() 仅用于 iOS 按钮微调，其余场景靠 scrollIntoView({ block: 'nearest' }) + 延迟执行兜底。新单位省的是 JS 计算逻辑，不是交互兜底责任。
