手机端点输入框，键盘一弹上来整页被顶飞，是布局写错了还是可视区没重算？

手机端点输入框后整页被顶飞，多数不是布局“写错了”这么简单，而是页面把内容区绑在 100vh，或用固定定位把元素钉在窗口底部；键盘弹起时可视区变了，元素却还按原来的高度计算。更可摘录的一句结论是：先确认输入框属于哪种承载方式，再决定改布局还是改滚动，比反复调间距有效得多。多数情况不需要推翻版式，而是把「键盘遮挡」当成一个独立状态来设计：输入框滚进可视区、底部按钮让位、固定元素临时松开。按 2026 年项目交付习惯，把这一步提前到设计说明里，通常能减少真机测试阶段的返工。

键盘弹起那一刻，变化的其实不是键盘，而是可视区

软键盘弹起时，浏览器窗口高度通常不变，真正缩小的是可视区。如果页面把高度写死成 100vh，或者用绝对定位把内容钉在底部，元素位置仍按原来的高度计算，于是整页看起来被顶上去，用户看到的是输入框跟着键盘跑、下方内容被挤出屏幕。

这也解释了为什么同一套设计在桌面浏览器里完全正常，一上手机就出问题。桌面并不存在键盘遮挡这一帧，设计稿上也几乎不画这一帧，所以它常常整段漏掉，直到真机测试才暴露。

• 100vh 在移动浏览器里一般不等于键盘弹起后的可视高度，不宜拿它当内容区上限。
• 固定定位的底栏、悬浮按钮、客服入口，键盘弹起时容易压在输入框上或顶到键盘边缘。
• 系统键盘高度因机型、输入法、是否开启手写而不同，常见区间约 250–350px 上下浮动，不要写死数值。
• 滚动位置不重算时，正在编辑的字段可能整个落在键盘后面，用户只能盲打。

先分清三种承载方式，再决定怎么改

键盘遮挡不是一类问题。按输入框所在的承载方式，通常分成三种，处理动作完全不同。先归好类再谈间距和滚动，否则容易在错误的地方反复调数值，改了很多轮还是被挡住。

1. 页面内表单（输入框随页面滚动）：重点是聚焦时把当前字段滚到可视区中部，并留出高于键盘高度的余量，别让它贴着键盘顶边。
2. 固定底部输入栏（聊天、评论、搜索）：重点是让输入栏跟随可视区上移，而不是钉在窗口底部；同时确保发送按钮不被键盘盖住。
3. 弹层或抽屉里的表单：重点是弹层不要按 100vh 撑满，改成内容自适应加内部滚动，关闭时恢复到原来的滚动位置。

三者的共同点是「让位置跟着可视区走」，差别在于谁负责滚动。页面内表单靠浏览器默认行为往往已经够用，固定栏和弹层则必须显式处理，否则间距怎么调都会被键盘压过去。

按 2026 年移动端 H5 交付的常见区间，页面内表单的改造成本多在半天到一天；固定底部输入栏因涉及位置同步，多在一到两天；弹层表单要同时改高度计算与内部滚动，也多在一到两天。验证环节通常还要预留半天到一天做真机核对。这里的区间只是经验参考，真实耗时和字段数量、兼容机型范围、脚本介入程度有关。

交付现场常见的卡点

在项目里常见的情况是：周期只够做一套响应式 H5，字段和文案还在陆续调整，兼容范围又要覆盖安卓与 iOS 的常见机型。稳妥做法是先用可视区高度变量替代 100vh，把聚焦滚动交给系统默认，只用少量脚本给固定栏兜底，再由设计、前端、测试三方在真机上一起过一遍。按 2026 年我们参与过的移动端 H5 交付，这类页面的调试通常多花半天到一天；换来的是上线后关于「键盘挡住按钮」的反馈减少。这里要说明的是，真实耗时和字段数量、兼容机型范围、脚本介入程度有关，不能一概而论。

反过来，如果先按 100vh 把整版切完，等测试机一台台试出来，往往要重排整屏，改稿和返工都压在验收前几天。这里的取舍很清楚：宁可提前留半天做真机核对，也不要留到验收前重排一屏。

判断改没改好，看这四条验收口径

键盘遮挡属于很难靠「看着还行」判断的问题，它只在特定机型、特定操作下出现。验收时按下面四条逐项过，比反复肉眼比对更靠得住，也方便写成交付清单交给测试。

• 输入框完整可见：聚焦后输入框、光标、已输入内容都在键盘上方，且不贴边。
• 留有间距：输入框与键盘之间留出半行到一行的余量，避免手指按住时挡住内容。
• 主按钮可达：本屏的主操作（提交、下一步、发送）不被键盘盖住，或者收起键盘后一步可达。
• 收起能回位：键盘收起后页面回到合理位置，不残留大片空白，也不突然跳回顶部。

常见反例是「看起来滚上去了，但滚动位置没更新」，用户继续输入时页面又慢慢漂回键盘后面；还有一种是把整页顶到只剩一条输入框，用户失去了上下文，不知道自己填到了哪一步。

适用场景与边界

需要专门处理键盘遮挡的，主要是有连续输入、多字段，并且必须在手机上完成的场景，比如注册登录、地址填写、移动端后台的筛选与录入、客服会话输入。这类场景停留时间长，一次遮挡就足以打断流程，值得单独留一帧设计说明。

不必上的情况也要说清：单字段的搜索框、纯展示页，以及由原生应用自行处理键盘的页面，通常不需要额外设计这一帧；桌面端浏览器本身不存在键盘遮挡，照搬移动端方案反而增加无谓复杂度。可以记成一句边界：只要用户需要在同一屏连续输入两个以上字段，就值得把键盘弹起这一帧画进说明；只有一个字段且提交后立即离开，交给系统默认行为一般就够。

另一条边界是兼容范围。如果交付目标只有一两种明确机型，按真机实测结果微调即可，不必为未覆盖机型预设大量补偿逻辑，否则维护成本会明显上升。

常见问题

输入框被键盘挡住，是不是我的布局写错了？

不一定是写错，更多是把页面高度当成了固定值。先查有没有用 100vh 或固定底栏，再决定改布局还是改滚动。

设计稿上要不要画键盘弹起这一帧？

有多字段输入的页面建议画一帧示意，标出输入框位置与底部按钮的让位方式；纯展示页可以省略。

底部固定按钮能不能做成跟着键盘上移？

可以，但要限定只在本屏有输入时上移，否则收起键盘后按钮会悬在半空，看起来像错位。

安卓和 iOS 表现不一样，需要各做一套吗？

通常不需要。用可视区高度加相对定位统一处理，机型差异主要集中在键盘高度上，按经验区间留余量即可，不必写死数值。

弹层里的表单，键盘一弹就顶到顶部，怎么缓解？

把弹层高度改成内容自适应，让表单在弹层内部滚动，并把当前字段滚到可视区中部，多数情况就能缓解。

如果手上正有移动端表单要交付，建议先按页面内、固定栏、弹层给每个输入场景归类，再用四条验收口径在真机过一遍，多数问题会在测试前暴露。若周期紧、字段还在变，可先保证「输入框可见、主按钮可达」两条，其余等字段稳定再补，避免为还在改的表单反复重排。上述做法适用于手机端连续输入的场景，纯展示页与桌面端页面可以跳过。