visualviewport.offsettop 在虚拟键盘弹出时不可靠。chrome 82+ 中 offsettop 仅响应地址栏收起/展开或页面缩放，不随软键盘弹出变化；软键盘被浏览器视为覆盖层，不影响 visualviewport 尺寸与偏移，需通过 window.innerheight 突变配合防抖检测。
VisualViewport.offsetTop 在虚拟键盘弹出时是否可靠
不可靠。Chrome 82+ 虽然支持 VisualViewport，但 offsetTop 并不反映虚拟键盘遮挡高度，它只在页面被强制缩放（如双指缩放）或地址栏收起/展开时变化，和软键盘无关。很多开发者误以为它能监听键盘弹起，结果发现值始终为 0 或无响应。
为什么 offsetTop 不随软键盘变化
因为软键盘属于系统级输入法 UI，它不会触发 VisualViewport 的 resize 或 scroll 事件，也不会改变 visualViewport.offsetTop 或 height。浏览器将软键盘视为「覆盖层」而非「视口收缩」，所以 VisualViewport 的尺寸和偏移量维持原样。
-
visualViewport.height在键盘弹出前后通常不变（仍接近window.innerHeight） -
visualViewport.offsetTop只在地址栏隐藏（如滚动页面）时从 0 变为正数，与键盘无关 - Android Chrome 和 iOS Safari 均未将软键盘纳入
VisualViewport的计算逻辑
实际可用的软键盘高度检测方案
目前稳定可行的方式只有监听 window.innerHeight 的突变，并配合防抖和上下文判断：
- 在
focus事件触发后（如input或textarea获取焦点），记录当前window.innerHeight - 用
resize事件监听窗口高度变化，若新高度明显小于原高度（如差值 > 150px），大概率是软键盘弹出 - 需加 100–300ms 防抖，避免滚动、横竖屏切换等干扰
- iOS 上可结合
keyboardWillShow（仅 Safari 16.4+ 实验性支持，需webview配置）；Android 则完全依赖resize+innerHeight对比
示例关键逻辑：
let originalHeight = window.innerHeight;
window.addEventListener('focusin', (e) => {
if (e.target.matches('input, textarea, [contenteditable]')) {
originalHeight = window.innerHeight;
}
});
window.addEventListener('resize', () => {
const delta = originalHeight - window.innerHeight;
if (delta > 150 && delta <h3>容易被忽略的边界情况</h3><p>软键盘检测不是“有高度差就一定是键盘”，这些情况会干扰判断：</p>
- 用户切换应用再切回，
resize可能触发但无焦点元素 → 需结合document.activeElement校验 - 某些 Android 厂商定制键盘（如小米、华为）不收缩视口，
innerHeight完全不变 → 此时只能退回到滚动定位 +scrollIntoView补救 - iOS 17+ 的「浮动键盘」模式下，
innerHeight可能只减少 50–80px → 阈值不能硬设 150，建议动态基线校准 -
visualViewport的scale变化会同时影响innerHeight和布局，需排除缩放干扰
真正鲁棒的方案往往要组合 focusin、resize、scroll 和元素位置计算，而不是依赖某一个属性。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
