最可靠禁用软键盘的方式是源头切断触发条件：用readonly使input可聚焦但不弹键盘，或用disabled彻底禁用交互；app端必须配置softinputmode:"adjustresize"；多input共存时需全局排查。
直接禁用软键盘自动弹出，最可靠的方式不是“拦截”或“隐藏”，而是从源头切断触发条件：让 input 无法获得焦点，或获得焦点但不唤起输入法。不同场景下适用的方案差异很大，选错会导致闪屏、焦点丢失、iOS/Android 行为不一致等问题。
用 readonly 让 input 可聚焦但不弹键盘
这是兼顾交互与控制的常用解法。用户能点击选中文本、触发 @focus 事件，但系统不会拉起软键盘。
关键点：
-
readonly在所有平台（App、H5、小程序）都生效，且无样式副作用（不像disabled会置灰） - 它不影响
v-model绑定和程序赋值，只禁用用户输入 - 若需后续转为可编辑，只需动态切换
:readonly="isReadonly"
示例：
<input type="text" :readonly="true" v-model="value" placeholder="只读但可选中">
用 disabled 彻底禁用 input 交互
当输入框纯属展示用途（如订单号、状态标签），disabled 是最干净的选择——既不聚焦、也不响应点击、更不弹键盘。
注意坑点：
- 部分安卓机型在
disabled状态下仍可能短暂唤起键盘（尤其配合autofocus时），务必检查模板中是否误写了autofocus - 微信小程序里，
disabled的input仍可能被KeyboardAvoidingView类组件错误识别为可输入区域，导致布局异常 - 如果需要保留点击反馈（比如跳转详情页），建议外层套
<view></view>，而非依赖 input 自身事件
App 端必须配 softinputMode: "adjustResize"
仅靠前端属性无法解决 Android 键盘遮挡引发的连锁问题。很多“键盘反复弹出”“页面抖动”“输入框失焦后又自动聚焦”的现象，根源是 WebView 容器未正确响应键盘生命周期。
必须在对应页面的 pages.json 中显式配置：
"app-plus": { "softinputMode": "adjustResize" }
不配这个，adjust-position="true" 和 cursor-spacing 都是无效的。它和 readonly 不冲突，而是底层协同机制：
-
adjustResize告诉系统：键盘弹出时，把 WebView 高度压缩，触发布局重排 - 没有它，即使 input 不弹键盘，页面也可能因键盘占位而错位，间接诱发焦点异常
- H5 和小程序无需此项，只对 App 端（
APP-PLUS）生效
慎用定时器反复调 uni.hideKeyboard()
虽然网上大量教程推荐用 setInterval 每 20ms 调一次 uni.hideKeyboard()，但这属于兜底手段，有明显副作用：
- 首次聚焦时仍会闪一下键盘（哪怕只有 100ms），尤其在低端安卓机上更明显
- 若页面跳转未清除定时器，会造成内存泄漏，甚至影响后续页面的键盘行为
- 在 iOS 上，频繁调用
uni.hideKeyboard()可能触发系统保护机制，导致后续focus()失效 - 微信小程序中该 API 仅在特定基础库版本支持，低版本直接静默失败
真正需要它的情况极少：比如你正在对接物理外设键盘，且必须保证任何意外焦点都不会暴露软键盘——此时才建议封装成 mixin，在 onUnload 中主动 clearInterval。
最易被忽略的一点：多个 input 共存时，只给其中一个加 readonly 或 disabled 不够。只要任一可交互 input 存在，页面就可能因生命周期或 focus 逻辑被系统判定为“需输入场景”，从而在某些安卓 ROM 上强制唤起键盘。务必全局排查。
