inputmode属性仅控制软键盘类型，无法解决键盘遮挡问题；真正有效的是scrollIntoView()配合focus时机控制，并需注意viewport设置、autocomplete正确用法及iOS下display/visibility状态影响。
input 的 inputmode 属性为什么不能解决键盘遮挡
它只控制软键盘类型（比如数字键盘、邮箱键盘），不触发页面滚动或视口调整，对 iOS/Android 上输入框被键盘盖住的问题毫无作用。很多开发者误以为设了 inputmode="decimal" 就能“智能上推”，其实只是换了个键盘样式。
真正起效的是 scrollIntoView() + focus 时机控制
移动端键盘弹出时，浏览器不会自动滚动到聚焦的 input，尤其在 fixed 容器、底部表单或 WebView 中更明显。必须手动干预：
- 监听
focus事件，延迟 100–300ms 再调用element.scrollIntoView({ behavior: 'smooth', block: 'center' })（iOS Safari 对block: 'nearest'支持更稳） - 避免在
touchstart或click中立即调用 —— 此时键盘尚未开始弹出，scrollIntoView可能无效 - 对
position: fixed或transform父容器内的 input，需确保父容器有overflow: visible，否则scrollIntoView会被截断
viewport meta 的 height=device-height 是个危险陷阱
有人尝试用 <meta name="viewport" content="height=device-height"> 让视口“跟随键盘收缩”，结果是：Android Chrome 无视该属性，iOS Safari 会强制重绘并导致输入框跳动甚至失焦。这个属性早已被主流浏览器废弃，实际无效。
可靠做法只有两个：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 用
window.visualViewport监听高度变化（仅支持较新 Android/iOS），动态调整body的padding-bottom - 对微信 WebView 等环境，降级使用
resize事件监听窗口高度突变（注意防抖，因键盘弹出会连续触发多次）
autocomplete 属性和键盘遮挡基本无关，但容易被误配
autocomplete="off" 或 autocomplete="new-password" 只影响浏览器自动填充行为，不影响键盘位置。但若错误地给所有 input 都加 autocomplete="none"（非法值），某些旧版 UC 浏览器会禁用原生键盘输入法，反而加剧聚焦失败问题。
正确写法只在需要时设置：
- 密码字段用
autocomplete="current-password" - 手机号用
autocomplete="tel"（有助于唤起数字键盘，间接提升体验） - 完全不需要自动填充的场景，用
autocomplete="off"即可，不要拼错
键盘遮挡本质是视口与焦点位置不同步，不是语义或建议属性能解决的。最常被忽略的一点：iOS 上 scrollIntoView 在 input 处于 display: none 或 visibility: hidden 状态下根本不会生效 —— 动态显示 input 后，必须等 reflow 完成再 focus。
