input事件实现输入即响应实时过滤，需防抖、区分本地过滤与远程联想、处理iOS中文输入重复触发问题。
uni-app里用 input 事件做实时过滤，别等 blur 或 confirm
搜索框联想词和列表实时过滤的核心是「输入即响应」，不是用户点搜索按钮才触发。uni-app 的 input 事件在每次输入（包括删除）时都会触发，而 confirm 只在软键盘按回车/搜索键时触发，blur 更是失焦才执行——这会打断用户操作流，导致联想延迟或漏掉中间态关键词。
实操建议：
- 绑定
@input="onInput"，在onInput中直接更新filteredList或调用防抖后的请求函数 - 避免在
onInput里直接发请求，尤其未加防抖：用户连打 “shanghai” 会触发 9 次请求，后端可能限流，前端也浪费资源 - 若用
watch监听searchValue，记得加immediate: false，否则组件初始化就触发一次空查询
防抖要用 setTimeout + clearTimeout，别信 uni-app 自带的 debounce 方法
uni-app 官方 API 里没有内置防抖函数，有些插件或文档示例会封装一个 debounce 工具，但实际项目中更可控、更不易出错的是手写简易防抖逻辑。重点不是“多高级”，而是“能立刻知道它什么时候清、什么时候发”。
常见错误现象：联想词跳变、重复请求、上一次输入的请求覆盖了当前结果（比如搜 “beij”，返回“北京”，紧接着删成 “bei”，却仍显示“北京”）。
实操建议：
- 在 data 中定义
searchTimer: null -
onInput(val)里先clearTimeout(this.searchTimer)，再this.searchTimer = setTimeout(() => { this.fetchSuggestions(val) }, 300) - 如果用户快速输入又清空，
val为空字符串时，可直接清空联想列表，不发请求 - 请求函数
fetchSuggestions内部应校验val.length >= 2再发起，避免搜单字返回大量无意义结果
列表过滤和远程联想要分开处理，别混在同一个 computed 或 watch 里
本地列表实时过滤（比如从已有城市数组里筛）和远程获取联想词（比如调 /api/suggest?q=xxx）是两类动作：前者同步、零延迟；后者异步、有网络开销和竞态风险。混在一起会导致 UI 卡顿、结果错乱，甚至把上一轮的远程数据覆盖掉当前本地过滤结果。
使用场景举例：搜索框下方同时显示「历史搜索」（本地数组）和「热门推荐」（接口返回），用户输入时，历史项应立刻过滤，而热门推荐需等接口返回后再合并渲染。
实操建议：
- 用两个独立响应式字段：
localFiltered（computed 或方法内同步计算）、remoteSuggestions（data 中定义，由接口赋值） - 渲染时用
v-for遍历[...localFiltered, ...remoteSuggestions]，但注意去重（比如用Set或id字段判重） - 远程请求成功后，检查当前
searchValue是否仍匹配本次请求参数，不匹配则丢弃该次响应（防止“搜 beij”发出请求，用户已删成 “bei”，结果还塞进来“北京”）
真机调试时 input 事件在 iOS 上可能触发两次，安卓正常
这是 uni-app 编译到微信小程序或 App 时的真实问题：iOS 端软键盘输入中文，选词确认后，input 事件会连续触发两次，第二次的 event.detail.value 是最终值，第一次可能是拼音或中间态。这会导致防抖失效、请求发两遍、UI 闪动。
性能与兼容性影响：安卓、H5 正常；iOS 尤其微信小程序环境最明显；App 端（iOS）也有类似表现。
实操建议：
- 在
onInput开头加简单比对：if (val === this.lastInputVal) return;，然后更新this.lastInputVal = val - 不依赖
event.target.value，统一用v-model绑定的变量，再配合watch或@input处理，更稳定 - 上线前务必在真机（特别是 iPhone + 微信）测中文输入全流程，光模拟器看不出问题
最麻烦的不是逻辑写不对，而是中文输入法在不同平台的行为差异没被提前识别。防抖、去重、竞态处理这些看似“通用”的技巧，在 uni-app 的跨端语境下，每一步都得对着真机调。
