focus事件中调用scrollIntoView({block:'nearest',inline:'nearest'})才真正有效，因iOS Safari在键盘弹出前触发focus，此时滚动能卡准时机；其他时机或配置错误（如user-scalable=no、未设height=device-height）均会导致失效。
focus 事件里调 scrollIntoView 才真正有效
软键盘遮挡不是样式问题，而是浏览器在焦点获取和视口重绘之间的时机错位。iOS Safari 在键盘弹出前就触发 focus，此时调用 scrollIntoView({ block: 'nearest', inline: 'nearest' }) 是唯一能“卡准点”的方式；写在 click 或 resize 里，Android 部分机型还没聚焦就滚动，iOS 则可能已错过最佳时机。
常见错误现象：
- 用了
behavior: 'smooth'—— 微信 X5 内核静默失败，光标不动 - 监听
window.focusin或document.activeElement变化 —— 触发延迟或重复，尤其在快速切换输入框时 - 对
textarea没单独处理 —— 它默认可滚动，scrollIntoView行为与input不一致，需加scrollTop = 0预置
实操建议：
- 绑定到每个
input和textarea元素自身的focus事件，而非委托 - 避免节流或防抖 —— 焦点事件本身是瞬时的，加延时反而失准
- 示例：
input.addEventListener('focus', () => {<br> input.scrollIntoView({ block: 'nearest', inline: 'nearest' });<br>});
viewport meta 写错，JS 就白跑
90% 的“滚动没反应”实际是 meta 配置锁死了浏览器对键盘弹出的感知能力。iOS Safari 依赖 visualViewport.height 变化来通知 JS，而这个变化被 user-scalable=no 或缺失 height=device-height 直接屏蔽。
立即学习“前端免费学习笔记（深入）”；
关键参数差异：
-
height=device-height必须存在 —— 否则window.innerHeight在键盘弹出后不变，JS 无法判断是否被压缩 -
user-scalable=no绝对禁用 —— iOS 会静默禁用 viewport 动态重绘，visualViewport.height永远等于屏幕物理高度 -
maximum-scale=1可保留，但不能搭配user-scalable=no—— 单独限制缩放不干扰键盘逻辑
推荐写法：
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=yes, height=device-height">Android Chrome 对
height=device-height 支持弱，但至少不会破坏已有逻辑；而 user-scalable=no 在 iOS 上是真·静默杀手，比不写还危险。
blur 时不恢复，页面就悬在半空
focus 时滚上去了，blur 时不处理，用户收起键盘后页面常卡在错误位置：底部留白、顶部内容被裁、再点其他输入框光标直接消失——这在 iOS 上尤为明显，因为系统不自动回滚。
难点不在“怎么滚回去”，而在“滚回哪”：
- 不能硬设
window.scrollTo(0, 0)—— 会打断用户浏览上下文 - 不能读
document.body.scrollTop—— iOS 上它常为 0，不可靠 - 应记录 focus 前一刻的
window.visualViewport?.pageTop || window.pageYOffset，作为回滚锚点
实操要点：
- 在
focus事件回调最开头取lastScrollTop，而不是在事件外定义变量 -
blur里加 200ms 防抖 —— 避免因键盘收起动画未完成就执行回滚 - 对 fixed 底部输入框（如聊天输入栏），blur 时需临时切回
position: absolute并重置bottom，否则回滚后定位错乱
inputmode + type 组合才是键盘类型控制的工程底线
单靠 type="number" 或 inputmode="numeric" 都不可靠。前者在 iOS 上吞前导零、转小数点为逗号、禁粘贴；后者在 vivo/OPPO 系统输入法中大概率被忽略。真正能落地的，是语义明确、真机验证过的组合。
经过 iOS 16.4+ 和 Android Chrome 120+ 多机型实测，稳态组合如下：
-
type="tel"+inputmode="numeric"：手机号、验证码首选，双保险触发带 *# 的数字键盘 -
type="email"+inputmode="email"：邮箱字段，@ 和 . 键出现概率显著提升 -
type="text"+inputmode="decimal"+pattern="[0-9.]+"：金额类输入，避开type="number"的类型转换陷阱
容易踩的坑：
- 写
inputmode="number"—— 这不是标准值，所有主流浏览器都忽略 -
type="text"+inputmode="tel"—— 语义断裂，自动填充失效，部分输入法不识别 - 只写
inputmode不配pattern—— 用户仍可粘贴非法字符，前端校验必须跟上
复杂点在于：同一套 HTML，在小米弹数字键，华为却弹拼音，这是系统输入法层决定的，前端最多做到“尽力提示”，无法 100% 强制。真正兜底的，永远是 oninput 过滤 + 提交前正则校验。
