h5端ios输入框被遮挡的根本原因是uni.onkeyboardheightchange不触发，须依赖window.innerheight变化+防抖阈值（>80px）模拟键盘高度，并用uni.createselectorquery查节点绝对位置配合scrollintoview或transform上推，cursor-spacing等app属性在h5端完全无效。
uni-app H5端iOS输入框被遮挡一半，根本原因不是CSS错位
这不是position: fixed没写对、也不是padding-bottom漏加——H5端（尤其iOS Safari）压根不触发uni.onKeyboardHeightChange，所有依赖这个API的逻辑都失效。它靠的是window.innerHeight变化 + 防抖检测来模拟键盘弹起，但iOS Safari在键盘弹出时会“假性缩放”视口，导致innerHeight先变小、再跳回、甚至抖动，直接用差值算高度必然出错。
监听window.innerHeight必须带防抖和阈值过滤
直接监听window.addEventListener('resize')会收到大量无效事件：键盘刚弹出时innerHeight可能只减10px，收起瞬间又多减20px，中间还夹杂着页面滚动、横竖屏切换等干扰。不加约束就会让输入框反复上蹿下跳。
- 用
setTimeout或lodash.debounce做300ms防抖，避免高频触发 - 只接受
innerHeight变化量 > 80px 的事件（iOS键盘真实高度通常240–280px，80是安全下限） - 记录上次有效
innerHeight，避免收起时误判为新弹出 - 别在
mounted里一次性绑定，应在@focus时才监听，@blur时removeEventListener，否则页面切走后还在吃CPU
滚动到输入框要查绝对位置，不能信e.detail.scrollTop
很多代码直接拿scroll-view的e.detail.scrollTop去uni.pageScrollTo，这在H5端完全无效——scroll-view是组件内滚动，uni.pageScrollTo操作的是整个页面文档流。iOS下更麻烦：键盘弹出后，document.documentElement.scrollTop可能还是0，但输入框实际已移出可视区。
- 必须用
uni.createSelectorQuery().in(this).select('.your-input-class').boundingClientRect()查节点 - 查完立刻用
getBoundingClientRect()再确认一次，因为Safari渲染延迟可能导致第一次查返回null或top: 0 - 滚动目标不是
top值本身，而是top - (window.innerHeight - keyboardEstimate)，其中keyboardEstimate取260px（iOS实测均值），比纯靠innerHeight差值更稳 - 加
duration: 200，太慢用户觉得卡，太快像抽搐
cursor-spacing在H5端完全不生效，别白配
cursor-spacing和adjust-position是App平台原生层属性，H5端编译后就是普通<input>标签，浏览器根本不认这两个prop。强行写上去不仅无效，还会让Vue警告“Unknown prop”，污染控制台。
- H5端唯一可控的是
scrollIntoView({ behavior: 'smooth', block: 'nearest' })，但iOS Safari对block: 'nearest'支持不稳定，建议降级为block: 'center'并配合手动偏移 - 如果输入框在
position: fixed容器里，滚动无效，得改用transform: translateY()临时上推整个容器 - iPhone X及以上机型需额外考虑底部安全区：
env(safe-area-inset-bottom)要在body或容器上设padding-bottom，否则键盘顶上来时按钮被安全区截断
H5端iOS的键盘适配没有银弹，softinputMode不生效、uni.onKeyboardHeightChange不触发、cursor-spacing被忽略——所有App端惯用手段在这里都要重写逻辑。最易被忽略的是：iOS Safari resize事件不可靠，必须用视口尺寸+节点位置双校验，且每次滚动前要等至少150ms让渲染管线稳定。
