软键盘弹出导致页面被顶起或遮挡的根本原因是浏览器动态调整视口高度，使依赖初始视口尺寸或fixed锚点的布局错乱；需通过viewport规范配置、focus/blur监听、flex替代fixed、visualViewport API适配及真机调试验证综合解决。
软键盘弹出后页面被顶起或遮挡
这是移动端最典型的布局错乱现象：用户点击 <input> 或 <textarea>，软键盘弹出，页面整体上移、内容被截断、固定定位的遮罩层（如弹窗）错位甚至消失。根本原因不是 CSS 写错了，而是浏览器在软键盘唤起时会动态调整视口（viewport）高度，而很多布局依赖的是初始视口尺寸或绝对定位锚点。
常见错误现象包括：position: fixed 的底部按钮被顶出屏幕、.iframe-cz 类遮罩层脱离预期位置、scrollIntoView() 失效导致输入框被键盘盖住。
- 必须监听
focus和blur事件，而非仅靠 CSS 修复 -
input.scrollIntoView(false)要配合定时器反复触发（因软键盘展开过程异步，单次调用常不生效） - 若遮罩层内含输入框，需在
focus时临时将遮罩层position改为absolute，避免被软键盘推离视口；blur后恢复fixed+bottom: 0 - 不要依赖
window.innerHeight做高度判断——软键盘弹出后它可能变小，但某些安卓浏览器仍返回原始值，不可靠
viewport 设置缺失或参数冲突
软键盘引发的布局重算，往往放大了 viewport 配置本身的缺陷。如果 <meta name="viewport"> 缺失或写法不当，浏览器在键盘弹出时无法正确缩放和重排，导致整个页面“抖动”或文字突然变小。
典型错误写法：<meta name="viewport" content="width=device-width"> —— 缺少 initial-scale=1.0，iOS Safari 会强制缩放；或写了 user-scalable=no，使键盘弹出后无法手动微调视图。
立即学习“前端免费学习笔记（深入）”；
- 必须确保
<head>中只有一条 viewport 标签，且包含width=device-width, initial-scale=1.0 -
maximum-scale=1.0可选，但慎用——它会禁用双击放大，在部分场景下反而加剧输入框定位失败 - 不要在 JS 中动态修改
document.documentElement.style.height后又忽略软键盘收起时的还原逻辑，否则页面高度残留异常
fixed 定位元素在软键盘场景下的失效
position: fixed 在软键盘弹出时行为不一致：Safari 会将 fixed 元素锚定到「视觉视口」（visual viewport），而 Chrome 安卓多数情况锚定到「布局视口」（layout viewport）。这直接导致同一段 CSS 在不同环境表现迥异——比如一个 bottom: 0 的 tabbar，在 iOS 上被顶起，在安卓上却稳如泰山。
使用场景：登录弹窗底部按钮、聊天输入框、遮罩层中的表单控件。
- 避免对关键交互区域（如提交按钮）单独依赖
fixed+bottom，改用 flex 布局 +margin-top: auto将其“撑”到底部 - 若必须用
fixed，需通过visualViewportAPI 监听高度变化（仅现代浏览器支持），并在resize事件中重设 top/bottom 值 - 微信内置浏览器不支持
visualViewport，此时只能降级为监听focus/blur+ 手动 scroll + DOM 重排补偿
真机调试时容易忽略的渲染差异
Chrome DevTools 的设备模拟器无法复现软键盘唤起的真实流程：它不会真正改变视口尺寸、不会触发 resize 事件、也不会影响 getBoundingClientRect() 的返回值。所有基于模拟器的“修复”都可能在真机上失效。
重点检查项：overflow: hidden 是否意外裁剪了被顶起的内容、transform: scale() 是否创建了新图层导致 z-index 异常、input 聚焦时是否触发了父容器的 height: auto 塌陷。
- Android 真机用
chrome://inspect连接，查看实时visualViewport.height和innerHeight差值 - iOS 真机必须用 Mac + Safari 开发菜单 → 设备名 → 检查网页，观察
fixed元素的 computedtop值是否随键盘变化 - 微信、QQ、支付宝等 WebView 有自己的 UA 和渲染策略，需单独测试，不能假设它们和标准浏览器一致
