微信里点开 H5 输入框，底下按钮就叠在键盘上，是代码写错还是容器本来就这样？

H5 输入框一聚焦，底下按钮就叠到键盘上，多数不是代码写错，而是键盘改变了可视视口高度，再叠上浏览器的自动滚动和 fixed 定位规则。2026 年做微信内 H5 时，先别急着关页面缩放，也别急着加 JS 补丁：先把「谁在变、谁在顶、谁在算」这三件事分开，再决定改哪一层。分不清这三层，就容易在不是病根的地方反复调数值。

键盘弹起来，变的是哪一层

很多开发者看到输入框聚焦后页面乱跳，第一反应是加 meta 禁止缩放。但 iOS Safari 里页面被放大，通常是因为输入框字号小于 16px，浏览器为了让你看清内容而自动缩放，这跟键盘顶起是两回事。键盘弹起改变的是 visualViewport，它一般不影响 layout viewport，所以用 vh 或 100% 算出来的高度不会跟着变。

真正容易出错的是三层叠加：可视视口变小、浏览器为了让输入框可见自动滚动、页面自己写的 scrollTop 修正。三者方向经常不一致，表现就是输入框跳一下、吸底按钮飘一下、收起键盘后底部留一片白。

• 布局视口：多数移动浏览器里保持不变，用于排版计算，vh 参照的是它。
• 可视视口：键盘弹出后高度变小，可通过 Visual Viewport API 读取真实值。
• 滚动位置：浏览器会自动把聚焦元素滚进可视区，页面若同时改 scrollTop 就会打架。
• 固定定位元素：吸底按钮、底部 Tab 栏在部分容器里被顶起，另一些容器里则悬浮在键盘上方。
• 高度单位：100vh 在移动端常常不等于当前可视高度；dvh/svh 支持度已较好，但老 WebView 仍有缺口，需要百分比回退。

iOS、安卓、微信里为什么各长各的

同一份代码在 iOS Safari、安卓 Chrome、微信内置浏览器里表现不一致，是常态。iOS Safari 键盘弹起时基本不改布局视口，fixed 元素常见被顶到键盘上方；安卓 WebView 若宿主设了 adjustResize，布局视口会变小，若设了 adjustPan，则整页向上平移，吸底按钮跟着走。同一个「被顶乱」，在不同容器里根因并不相同。

微信内置浏览器在 iOS 和安卓上用的内核不同，小程序 web-view 又是一套独立容器。交付前要先确认这次覆盖哪些容器、哪些机型档次，而不是先去找一段通用代码。经验上，覆盖 iOS Safari、微信 iOS、微信安卓、安卓主流浏览器这四类，能拦掉大部分返工。

排查顺序：可视视口三问

我把这套顺序叫可视视口三问：谁在变、谁在顶、谁在算。这三类原因对应完全不同的修法——视口问题改高度取值，遮挡问题改布局层级，计算问题删掉多余的 JS。先把问题归到其中一类，再动手，返工概率会明显下降。

1. 谁在变：聚焦前后分别打印 visualViewport.height、window.innerHeight 和滚动容器高度，确认究竟哪一层变了。
2. 谁在顶：列出页面上所有 fixed / sticky 的吸底元素，逐个看聚焦时是被遮、被顶还是位置正常。
3. 谁在算：搜一遍 100vh、100%，以及任何在初始化时缓存过高度的变量，这类值在键盘收起后不会自动更新。
4. 先关 JS 兜底：临时注释 scrollTop 修正、scrollIntoView 等逻辑，看原生滚动是否已经够用；scrollIntoView 若在键盘动画结束前调用，位置通常会偏。
5. 再加最小补丁：只有原生不满足时才监听 visualViewport，并同步处理失焦复原；复原逻辑缺失是底部留白的高发点。

三种做法怎么选，附经验区间

做法本身没有优劣，关键是看交付容器和页面形态。下面按改动量、适用情况和不适用情况列一下，周期按经验区间给，实际浮动取决于要回归多少机型。

• 方案 A：纯 CSS 自适应（dvh/svh 加 flex 纵向布局，底部栏用 sticky）。改动量常见在半天以内；适合表单为主体、交付容器可控的页面；老安卓 WebView 不支持新单位时要用百分比回退，别只写一套。
• 方案 B：监听 visualViewport 动态设容器高度。含兼容回归的改动量常见 1～3 天；适合要覆盖多容器、吸底操作必须精确避让的场景；如果只在个别页面加而全局布局另有一套，容易互相干扰。
• 方案 C：交由客户端处理（自有 App 壳设置软键盘调整模式或键盘避让）。配置改动常见半天以内；只在能改壳的项目里有效，微信和第三方浏览器里没有这个开关，不能作为通用方案。

简单判断口径：页面只有一个输入框、没有吸底操作，优先走方案 A；多容器交付且吸底按钮必须常驻，走 A 加 B；自有 App 内嵌 H5，先问客户端能否从壳层解决，再决定前端要不要动手。

交付现场：三天上线时踩过的坑

按项目交付经验，问题常出在时间紧、容器多这两件事叠在一起。常见情况是：下单页要求三天内上线，要覆盖 iOS Safari、微信 iOS、微信安卓和安卓浏览器；为了快速对齐，先写了监听 resize 自动设容器高度的逻辑，结果 iOS 收起键盘后 resize 触发时机不稳，页面底部留出一条空白，安卓上滚动位置又被抢，最终退回以 CSS 为主、JS 只做失焦复原，前后多花约两天（经验区间）。约束没提前讲清，代价通常体现在回归阶段。

• 只缓存一次 window.innerHeight，键盘收起后用的还是旧值。
• 聚焦时给 body 加 overflow:hidden，收键盘后滚动位置丢失。
• 输入框字号小于 16px，iOS 自动放大，看起来像被顶飞。
• 吸底按钮写在 fixed 层里，与键盘区域重叠，点击被吞掉。
• 只在模拟器或桌面浏览器调试，真机才暴露问题。

验收口径可以落到五条：聚焦后输入框完整可见，不被键盘或吸底栏遮挡；失焦后页面高度与滚动位置复原，不出现多余空白；页面不横向滚动也不整体缩放；iOS、微信、安卓至少各一台真机通过；吸底按钮在键盘弹出时的行为符合设计预期，隐藏、上移或下沉三选一，并写进验收清单。

适用与不适用边界

适合处理的情况比较明确：下单、登录注册、评论、搜索建议这类强输入页面；自有 App 内嵌 H5；以及交付要求明确覆盖多个浏览容器的项目。这些场景里，键盘避让直接关系到能不能完成操作，值得单独排一点工期。涉及多机型回归的工作量，通常按容器数量单独排，不和主功能开发挤在同一条时间线上。

边界也很清楚：纯展示型长页、只有单个搜索框且不需要吸底操作的后台页，通常不必为此引入可视视口监听。如果一个页面键盘弹出时输入框本身仍在可视区、也没有吸底操作，那么再加可视视口监听多半只会增加维护成本。这类页面把输入框字号提到 16px 左右，配合原生滚动，一般就够了。

常见问题

关掉页面缩放能解决键盘顶起吗？

一般不能。禁止缩放只影响聚焦时的自动放大，而键盘改变的是可视视口高度，两者不是同一个问题，需要分开处理。

用 100vh 的页面，为什么键盘弹出后底部按钮会被遮住？

因为 100vh 参照的是布局视口，键盘弹出时它常常不变，页面照旧按整屏高度排版，底部区域自然落进键盘范围。

微信里正常，iOS Safari 里错位，先改哪边？

先按要求较严的容器改，通常是 iOS Safari，改完再回微信回归，避免两边同时动导致问题来源分不清。

键盘收起后底部留白，一般是什么原因？

常见是 JS 动态设过容器高度或滚动位置，却没在失焦时复原；也可能是 resize 监听在 iOS 上触发时机不稳。

如果页面是强输入场景、又要在多个容器里交付，建议按先算对高度、再做最小 JS 补丁的顺序推进，并在真机上留出至少半天回归时间（经验区间）。反过来，纯展示页或没有吸底操作的页面，先确认键盘弹出时输入框本身是否可见，可见就不必额外加补丁。判断依据可以按官方文档与各容器规范核对，别只凭一段复制来的代码就上线。