小屏安卓机上 Flutter 登录页键盘一弹，输入框就钻到键盘底下了，只能整页改成滚动吗？

多数时候不是键盘高度取错了值。真正的原因是 Scaffold 的 resizeToAvoidBottomInset 默认生效，会从 body 的可用高度里扣掉键盘占用的那部分；页面里再写死屏幕高度，或主体放在不可滚动的 Column 里，就成了「整页往上顶、输入框还是被遮」。2026 年常见的排查顺序是先分清三件事：谁改了高度、页面能不能滚、底部间距有没有被扣两次，再决定动不动那一行属性。

键盘弹起时，到底是谁把页面改短了

Flutter 不会直接改你的布局。键盘通过 MediaQueryData.viewInsets.bottom 上报被占用的高度，Scaffold 读到这个值，在 resizeToAvoidBottomInset 为 true（默认值）时压缩 body。收缩本身是正常行为，问题多半是页面没为收缩做准备。

跨端差异要提前认清：Android 侧常见做法是 windowSoftInputMode 配 adjustResize，窗口本身会缩；iOS 键盘不改变窗口尺寸，只上报 inset。同一页面两端表现不一样，往往是宿主把 adjustResize 换成了 adjustPan，页面变成整体平移，而不是被压缩。

一条能复用的「三看一量」

• 看宿主配置：Android 是否被改成 adjustPan，iOS 是否有自定义容器接管了键盘通知。
• 看有没有写死高度：拿 MediaQuery 的屏幕高度直接当 height 用，收缩后很容易溢出，常见表现是底部黄黑条纹。
• 看能不能滚：不可滚动的 Column 配 Expanded 或 Spacer，收缩只会挤压子项，焦点不会自动滚进可视区。
• 量 viewInsets：自己加过 viewInsets.bottom 间距的，确认没和自动收缩叠加、把高度扣了两次。

第四步最容易被跳过：同一段间距在 Android 上正常、iOS 上却多出一截空白，多半就是叠了两次。

两种做法怎么挑，看页面形态不看偏好

下面这组对比按 2026 年常见交付情况整理，耗时是经验区间，随字段数量和弹层数量浮动，不是承诺值。

• 方案 A：保留自动收缩，主体放进可滚动容器。改动面小，适合字段多、本来也该滚的表单；经验区间约 0.5~1.5 人天；代价是底部固定按钮、常驻底栏会被顶到键盘上方，得单独决定隐藏还是固定。
• 方案 B：关掉自动收缩，用 AnimatedPadding 配 viewInsets.bottom，只给输入区让位。改动面集中在中部，适合聊天、评论、底部固定输入栏这类「页面不动、只有输入栏动」的场景；经验区间约 0.5~1 人天；代价是安全区和横屏要自己算，之后每加一个输入相关组件都要再过一遍，长期维护成本更高。

还有一条边界要单独说清：页面内嵌 WebView、输入发生在 H5 里时，优先交给 WebView 自己的滚动与 inset 处理，不要在 Flutter 层再扣一次，否则会出现典型的「顶两次」，输入框被推得比键盘还高。

交付现场：一次只在小屏上暴露的返工

约束是两周迭代、预算已经压得很紧、兼容清单只写了「主流机型」，没有列小屏。我们的做法是不把键盘适配单独排进需求评审，而是自己写进提测清单：提测前先拿一台小屏安卓机加一种第三方中文输入法，在候选栏展开状态下把登录页完整走一遍。结果是提测当天就发现两处问题——底部提交按钮被推到键盘上方、离手指更远，弹层里的输入框则完全没有可滚动容器。按经验区间，这两处改完约多花 1~3 人天；如果等测试提出来，底部按钮、弹层层级、滚动位置往往会三处一起返工，还有拖到发版前一天的风险。

同类项目里反复出现的几个点：

• 安全区重复加：外层 SafeArea 与手动 bottom padding 叠在一起，键盘收起后底部仍留一条空白。
• 常驻底栏被推上去：bottomNavigationBar、persistentFooterButtons 跟着收缩上移，需要按场景决定隐藏还是固定。
• 中文候选栏更高：按英文键盘调好的间距，候选栏展开后仍然被挡，建议直接按展开态验收。
• 弹层里的输入框：Dialog 与 showModalBottomSheet 不跟键盘移动，内容要单独加滚动。
• 横屏与小屏：键盘常占掉一半以上高度，常见区间 50%~65%，这时先保证输入框可见，再谈视觉留白。

适用与不适用边界

这套排查适用于表单、登录、搜索、评论、聊天等页面内有输入的场景，尤其是同一份代码要同时上 Android 与 iOS 的跨端项目。它不适用于全屏视频、游戏、纯展示页——这些页面键盘极少出现，硬做适配只是多一个维护点；也不适用于以键鼠为主的桌面端布局，那类约束条件并不相同。

可以直接摘录的边界是：当输入发生在内嵌 WebView 的 H5 里，或弹层由原生壳接管时，问题往往不在 Flutter 布局层，而应先到宿主侧确认 inset 是否被处理了两次，再决定要不要动页面代码。按 2026 年的项目节奏，先分层归因这一步，通常能省掉大半无效改稿。

常见问题

关掉 resizeToAvoidBottomInset 就不顶了吗？

不一定。它只是把压缩的职责交回给你，页面里若还有写死的屏幕高度、或缺少可滚动容器，键盘弹起照样会溢出，只是现象从被压变成被挡。

为什么 iOS 上页面没被压缩，输入框还是被挡？

iOS 键盘不改变窗口尺寸，只上报 viewInsets。页面本身不可滚动时不会自动让位，需要给主体加可滚动容器，或在输入区手动留白。

底部按钮被键盘顶上去算 bug 吗？

不算，那是自动收缩的正常结果。要按场景决定是隐藏、固定在键盘上方，还是让整页可滚，这三种做法的验收口径并不相同。

内嵌 WebView 里的输入框被挡，该在 Flutter 层改吗？

通常先不改。先看 H5 自身的滚动与 WebView 对 inset 的处理，两层同时让位会出现顶两次，输入框被推得比键盘还高。

下次再遇到键盘把页面顶起来，先按「三看一量」确认问题出在自动收缩、写死高度还是重复扣 inset，再按页面形态在方案 A 和方案 B 之间挑一个；改完至少用小屏机加中文候选栏展开态过一遍。页面里若还有 WebView、原生壳或弹层，先分层再动代码，避免两边同时让位。