能，但仅App端生效；H5和小程序不触发，需降级处理；web-view内需动态调整高度并配置softinputMode；textarea需合理设置cursor-spacing与adjust-position。
uni.onKeyboardHeightChange 能监听到键盘高度吗？
能，但只在 App 端（iOS/Android）生效，H5 和小程序完全不触发。这是最常被忽略的前提——很多人写了监听却没效果，不是代码错，是平台不支持。uni.onKeyboardHeightChange 是 5+App 特有的原生事件，返回 { height: number }，单位为 px。它在键盘弹起、收起、甚至用户拖动键盘高度时都会触发，比单纯监听 focus/blur 更可靠。
- Android 上一般能稳定拿到真实高度（如 250–300px）
- iOS 上部分机型（尤其是带小键盘或缩放的场景）可能返回 0 或抖动值，需加防抖和最小阈值过滤（比如
height > 50</code 才认为是有效弹起） - H5 端必须降级：靠
window.innerHeight变化 + 定时检测视口收缩来模拟，但精度差、有延迟，仅作兜底
web-view 里的 input 被盖住，光调 adjust-position 没用？
对，adjust-position="true" 在 <input> 或 <textarea> 上只影响 uni-app 自己渲染的组件，对 <web-view> 内部的 H5 页面完全无效。web-view 是一个独立的浏览器内核容器，它的布局不受 Vue 模板层控制。真正有效的解法，是动态调整 <web-view> 组件自身的高度，让它“感知”到键盘占位。
- 必须配合
pages.json中的配置："app-plus": { "softinputMode": "adjustResize" }，否则原生层不下发高度变化事件 -
webview-styles.height不能写死，要设为响应式变量（如:height="webviewHeight"），键盘弹起时赋值为screenHeight - keyboardHeight - statusBarHeight - topOffset - 切忌直接设
height: 'auto'或null：某些 Android 机型会触发重绘异常，建议始终传明确数值（哪怕只是screenHeight - 20）
为什么 iOS 上 web-view 输入框还是卡在底部不动？
因为 iOS 的 adjustResize 行为本身就有缺陷：它会压缩整个页面可滚动区域，但 web-view 内部的 document.body 并不会自动触发 scrollIntoView，尤其当输入框在固定定位（position: fixed）容器里时，几乎必然被盖住。
- 解决方案不是让 H5 页面自己滚动（不可靠），而是让 web-view 容器“变矮”，把内部内容自然顶上来
- 需在监听到键盘高度后，立刻更新
webview-styles，并加nextTick或setTimeout(..., 0)确保样式应用时机 - iOS 还有个隐藏坑：键盘收起时，
height恢复后若未触发一次强制 layout（比如改个transform），可能出现“残留遮挡”，建议收起后补一句myWebview.value?.reload()（慎用，仅调试期验证逻辑）
textarea 的 cursor-spacing 和 adjust-position 怎么配才不翻车？
这两个属性只对 uni-app 原生 <textarea> 有效，且参数敏感：
-
cursor-spacing是光标离键盘顶部的距离，不是离输入框底部。设太小（如 20）会导致光标紧贴键盘，用户看不见自己打的字；设太大（如 300）又会让输入框猛往上跳，破坏布局节奏。实测 120–160 是较稳区间 -
adjust-position="true"在 Android 上基本可用，在 iOS 上有时失效（尤其嵌套在scroll-view里时），此时必须配合scroll-into-view手动滚动 - 注意：
adjust-position="false"并非“禁用调整”，而是交由原生默认行为处理，反而更不可控，不推荐设为 false
web-view 场景下，别指望这些属性能救 H5 页面；而原生组件场景下，它们只是辅助，真正的防线永远是 softinputMode + onKeyboardHeightChange + 主动布局计算。最麻烦的从来不是“怎么写”，而是“什么时候写、在哪一层写、对谁生效”。
