移动端输入框聚焦后按钮被键盘挡住怎么办：用 visualViewport 做底部适配

移动端 H5 表单里，经常会出现一个问题：用户点进输入框后，系统键盘弹起，页面底部的“提交”“下一步”“保存”按钮被挡住。用户看不到按钮，只能先收起键盘再点，流程被打断；有些页面还会因为固定定位失效，按钮停在键盘后面。

这个问题不是简单把按钮改成 position: fixed 就能解决。移动端浏览器会在键盘弹起时改变可视区域，iOS、Android、微信内置浏览器的表现也不完全一致。本文按常见问题方式，从用户任务、交互时间线、组件实现、可访问性和边界状态逐步处理。

用户任务：键盘弹起时仍要完成提交

先把问题说清楚：用户正在填写表单，焦点在输入框里，下一步动作是点击底部按钮。如果按钮被软键盘遮住，用户要么不知道下一步在哪里，要么必须多做一次“收起键盘”的动作。

常见症状包括：

• 按钮使用 position: fixed; bottom: 0;，键盘弹起后仍贴在屏幕底部，被键盘盖住。
• 页面被浏览器自动滚动，输入框可见了，但底部操作区消失。
• 按钮浮起来了，但距离键盘太近，手指误触概率变高。
• 键盘收起后按钮没有回到底部，页面留下空白区域。

目标不是“键盘弹起时页面不动”，而是“输入框、提示信息和主要操作按钮都处于当前可视区域内”。这也是后面实现的判断标准。

交互拆解：先确认是谁挡住了按钮

移动端键盘弹起时，页面会经历几个阶段：用户聚焦输入框，浏览器缩小可视区域，布局重新计算，最后按钮应该移动到键盘上方。排查时要看的是可视区域高度是否变化，以及底部按钮是否根据变化更新位置。

可以先在页面里临时打印两个值：

function logViewport() {
  const viewport = window.visualViewport;
  console.log({
    innerHeight: window.innerHeight,
    viewportHeight: viewport ? viewport.height : null,
    viewportOffsetTop: viewport ? viewport.offsetTop : null,
  });
}

window.visualViewport?.addEventListener("resize", logViewport);
window.visualViewport?.addEventListener("scroll", logViewport);

如果键盘弹起后 visualViewport.height 明显变小，说明浏览器提供了可用的可视区域信息。此时可以根据它计算底部偏移。如果没有变化，则要走降级方案，例如在输入框聚焦时给按钮留出固定高度，并在失焦后还原。

组件实现：用 visualViewport 计算底部偏移

核心思路是：底部按钮默认贴近安全区；键盘弹起后，根据布局视口和视觉视口的高度差，计算按钮应该上移多少。

.mobile-form {
  min-height: 100vh;
  padding-bottom: 88px;
}

.mobile-action-bar {
  position: fixed;
  left: 0;
  right: 0;
  bottom: calc(env(safe-area-inset-bottom) + var(--keyboard-offset, 0px));
  padding: 12px 16px calc(12px + env(safe-area-inset-bottom));
  background: #fff;
  border-top: 1px solid #e5e7eb;
  z-index: 20;
}

然后用 JavaScript 更新 CSS 变量：

function updateKeyboardOffset() {
  const viewport = window.visualViewport;
  const root = document.documentElement;

  if (!viewport) {
    root.style.setProperty("--keyboard-offset", "0px");
    return;
  }

  const hiddenHeight = window.innerHeight - viewport.height - viewport.offsetTop;
  const offset = Math.max(0, Math.round(hiddenHeight));
  root.style.setProperty("--keyboard-offset", `${offset}px`);
}

function bindKeyboardOffset() {
  const viewport = window.visualViewport;
  if (!viewport) return;

  viewport.addEventListener("resize", updateKeyboardOffset);
  viewport.addEventListener("scroll", updateKeyboardOffset);
  updateKeyboardOffset();
}

这段代码没有直接操作按钮样式，而是只更新根节点上的 CSS 变量。好处是组件结构更清晰：JS 负责读浏览器状态，CSS 负责布局表现。

可访问性：按钮可见还要能被正确读到

按钮浮到键盘上方后，还要保证辅助技术和键盘操作能理解这个区域。至少检查三点：

• 按钮文案要明确，例如“提交订单”“下一步”，不要只写“确定”。
• 表单错误提示要和输入框关联，避免按钮可见但用户不知道哪里错。
• 按钮禁用时要给出原因，比如必填项未填或格式不正确。

一个简单的错误提示结构如下：

手机号
请输入 11 位手机号

移动端体验里，按钮不被遮挡只是底线。更完整的体验是：用户知道当前填什么、哪里错了、下一步按钮为什么可点或不可点。

性能检查：不要让 resize 触发频繁重排

键盘弹起和收起期间，visualViewport 可能连续触发 resize 和 scroll。如果每次事件都立刻读写大量 DOM，就容易引发布局抖动。建议把逻辑收敛到一个小函数，只更新一个 CSS 变量。

let frameId = 0;

function scheduleKeyboardUpdate() {
  if (frameId) return;

  frameId = window.requestAnimationFrame(() => {
    frameId = 0;
    updateKeyboardOffset();
  });
}

window.visualViewport?.addEventListener("resize", scheduleKeyboardUpdate);
window.visualViewport?.addEventListener("scroll", scheduleKeyboardUpdate);

检查时可以打开浏览器性能面板，观察键盘弹起阶段是否出现长时间的脚本运行和连续布局计算。对于普通表单，更新底部偏移不应该造成明显掉帧。

边界状态：旋转屏幕、收起键盘和旧浏览器

问题修好后，还要验证几个边界状态。最容易漏的是键盘收起后按钮没有回位，或者横屏后偏移值仍沿用竖屏数据。

建议按下面的顺序复查：

• 输入框聚焦：按钮移动到键盘上方，并留出可点击间距。
• 输入框失焦：按钮回到底部安全区，没有残留空白。
• 屏幕旋转：重新计算偏移，不沿用旧高度。
• 长表单滚动：输入框和错误提示仍保持可见。
• 不支持 visualViewport 的浏览器：至少不出现按钮错位，可用固定键盘高度兜底。

降级方案可以保持简单：聚焦时给底部区域增加一个保守高度，失焦后清零。它不如 visualViewport 精准，但能避免完全不可操作。

function bindFallbackOffset() {
  if ("visualViewport" in window) return;

  document.addEventListener("focusin", (event) => {
    if (event.target instanceof HTMLInputElement || event.target instanceof HTMLTextAreaElement) {
      document.documentElement.style.setProperty("--keyboard-offset", "280px");
    }
  });

  document.addEventListener("focusout", () => {
    document.documentElement.style.setProperty("--keyboard-offset", "0px");
  });
}

总结

移动端输入框聚焦后按钮被键盘挡住，根因通常是底部固定区域没有跟随视觉视口变化。处理思路是：先确认 visualViewport 是否能反映键盘弹起；再用 CSS 变量控制底部偏移；同时检查可访问性、事件频率和边界状态。最终验证标准很直接：聚焦输入框、输入内容、查看错误提示、点击底部按钮，整个流程都不需要用户额外收起键盘。