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) 会破坏用户已有滚动位置（比如表单填到一半，突然跳回顶部）。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 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，延迟值必须实测验证，不能硬编码。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
