iOS上window.innerHeight突变是因为Safari主动压缩布局视口高度,导致fixed元素失锚、vh失准;Android Chrome仅缩视觉视口,布局视口不变。

为什么 iOS 上 window.innerHeight 会突变?
不是“键盘推高了页面”,而是 Safari 主动压缩了布局视口(Layout Viewport)高度。这个行为直接导致:position: fixed 元素失去锚点、window.innerHeight 值骤降(比如从 812px 掉到 500px)、vh 单位计算失准。Android Chrome 不会这样,它只缩视觉视口(Visual Viewport),布局视口保持不变。
关键影响:所有依赖视口尺寸的定位逻辑(比如底部按钮用 bottom: 0)都会失效;用 height: 100vh 做全屏容器时,键盘弹出后内容会被截断或错位。
scrollIntoView({ block: 'nearest' }) 必须加延迟
iOS 的 focus 和键盘动画不同步——focus 事件触发时,键盘还没完全展开,此时调用 scrollIntoView 会滚动到错误位置,甚至把输入框滚出视图外。
- 延迟时间选 400ms:iOS 键盘动画约 250ms,留 150ms 余量确保布局稳定
- 必须用
block: 'nearest':避免'smooth'在旧版 iOS 上卡顿或不触发 - 如果输入框在
position: fixed容器里,该容器父级需设overflow-y: auto,否则scrollIntoView找不到可滚动上下文
blur 后 window.scroll(0, 0) 不是万能解
键盘收起后页面没回弹,表面看是 window.scrollY 残留,但直接 window.scroll(0, 0) 会破坏用户已有滚动位置(比如表单填到一半,突然跳回顶部)。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图,自动匹配视觉风格。触发场景:文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记(深入)”;
更稳妥的做法:
- 记录 focus 前的
window.scrollY,blur 时还原(而非强制归零) - 仅对底部输入框做此处理,顶部/中部输入框通常无需干预
- 避免在
blur中立即执行 scroll,加setTimeout(..., 10)防抖,避开 iOS 的渲染抖动
CSS 层面要避开的三个隐形坑
很多偏移问题其实不是 JS 能修好的,根源在样式层:
- 禁用
height: 100vh:键盘弹出时 vh 值被 Safari 动态重算,但元素不会重排,导致高度塌陷或溢出 - 慎用
position: fixed套嵌:父 fixed + 子 absolute 在键盘弹出时极易错位,改用position: sticky或 flex 布局替代 - input 内部光标偏移:iOS 11+ 中 fixed 浮层内 input 的光标会随页面滚动偏移,临时方案是 blur 时重置
document.body.scrollTop和document.documentElement.scrollTop
底层修复的本质,是接受 iOS 视口行为不可控,转而用可预测的 DOM 滚动 + 可控的 CSS 布局兜底。最易被忽略的是:同一套 JS 逻辑在 iOS 13 和 iOS 16 上触发时机差异可达 100ms,延迟值必须实测验证,不能硬编码。


















