当前位置：首页 > 文章列表 > 文章 > 前端 > CSS如何解决移动端输入法遮挡布局_使用新视口单位lvh与svh适配

CSS如何解决移动端输入法遮挡布局_使用新视口单位lvh与svh适配

2026-05-05 23:54:44 0浏览收藏

“纵有疾风来，人生不言弃”，这句话送给正在学习文章的朋友们，也希望在阅读本文《CSS如何解决移动端输入法遮挡布局_使用新视口单位lvh与svh适配》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新文章相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！

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 事件兜底