最直接方案是使用input组件的confirm-type="search"属性触发软键盘搜索键，配合v-model绑定、@confirm监听及clearable属性，避免type="search"错误写法。
uni-app里用input实现搜索框最直接
不需要额外引入UI库，input组件原生支持confirm-type="search"，能触发软键盘的「搜索」按钮，这是最轻量、兼容性最好的起点。注意别写成type="search"——uni-app不识别这个type，只认confirm-type。
常见错误是绑定v-model后没监听@confirm或@blur，导致用户点搜索键无响应。实际场景中，用户更习惯按软键盘搜索键提交，而不是点页面按钮。
-
input需设placeholder提示文字，比如"搜索商品..." - 加
clearable属性（H5/小程序均支持）让输入框右侧出现清除图标 - 用
@input做实时过滤要谨慎——频繁触发可能卡顿，建议加防抖；搜索单次提交用@confirm更稳妥 - 安卓真机上
@confirm有时不触发，可降级监听@blur作为兜底
怎么让搜索框带「搜索按钮」且样式统一
很多项目要求右侧固定一个「搜索」文字按钮或放大镜图标，和input视觉连为一体。uni-app没有原生的searchbar组件，得手动拼接布局。
关键在flex布局和padding-right留白：给input加padding-right: 80rpx，再用position: absolute把按钮盖在右边。不要用float或inline-block，容易在不同平台错位。
- 按钮用
<button type="default" size="mini">搜索</button>，避免默认样式干扰 - 图标推荐用uni-icons插件的
<uni-icons type="search" size="18"></uni-icons>，比字体图标更稳定 - H5端需加
user-select: none防止长按选中文字影响点击 - 微信小程序里，
input聚焦时会自动顶起页面，若父容器有overflow: hidden可能导致按钮被裁切
搜索逻辑该放在组件内还是父页面
搜索框本身只负责收值和触发事件，**不要在组件内部发请求或管理loading状态**。它应该通过$emit('search', value)把关键词抛出去，由父页面决定查API、更新列表、还是跳转页面。
强行在组件里封装请求，会导致复用性差：比如首页搜商品、个人页搜订单，接口地址、参数、错误处理都不同。传参也容易混乱，比如是否需要page=1重置分页。
- 子组件定义
props接收disabled、placeholder等配置，但不接收apiUrl - 父页面监听
@search事件，调用this.searchList(keyword)方法 - 如果需要「回车即搜+按钮也搜」，两个动作都触发同一个
emit，别写两套逻辑 - 输入为空时
emit空字符串，由父页面判断是否拦截（比如禁止空搜）
为什么uni-app搜索框在iOS真机上经常失焦就收键盘
这不是bug，是iOS WebView对input的默认行为：失去焦点即隐藏键盘。用户点空白处、切后台、甚至手指滑动过快都可能触发。如果你做了下拉刷新或滚动区域，这个问题会更明显。
解决思路不是阻止失焦（不可靠），而是控制焦点时机。比如搜索按钮点击后，先this.$nextTick(() => inputRef.focus())再执行业务逻辑，确保键盘不闪退；或者在onPullDownRefresh里主动blur()已聚焦的input，避免下拉时键盘还挡着内容。
- 慎用
focus()自动聚焦——App启动时调用会弹出键盘干扰用户 - 使用
ref获取input实例时，H5用document.getElementById，小程序用this.$refs.inputRef，写法不统一 - 真机调试务必用自定义基座，普通浏览器模拟器无法复现键盘收起逻辑
搜索框看着简单，但跨端细节多：软键盘行为、焦点管理、事件触发时机、样式隔离。别急着套UI库，先把原生input的confirm-type、clearable、ref三个点吃透，后面加功能才不容易翻车。
