文章目录前言为什么这个问题经常被写乱小型索引适合本地数据实操步骤把关键代码一段段拆开端侧搜索不要额外存一份结果写在最后前言端侧搜索适合小数据、高频输入的场景。联系人、功能入口、城市列表这类内容如果每敲一个字都请求网络体验反而会被抖动拖慢。这篇单独聊联系人搜索这个场景。重点不是堆 API而是为小数据量建立端侧索引让高频输入时列表即时响应。为什么这个问题经常被写乱端侧搜索的小型索引 这类内容很容易被写成“代码能跑就算讲完了”但对初学者来说这恰恰是最不够的地方。真正让人卡住的往往不是某个组件名记不住而是不知道这段代码为什么要这样拆、状态为什么要这样放、以后需求变化时应该从哪里改。所以这篇文章不只想给你一个能跑的例子更想把背后的判断过程讲清楚。你只要把这个判断过程吃透后面自己改页面、补需求、查问题时心里会稳很多。小型索引适合本地数据联系人、城市、常用功能入口这类数据量不大没必要每输入一个字就请求服务端。端侧先建一个简单索引体验会顺很多也能减少网络抖动带来的空白。实操步骤原始数据保留name/phone/keyword。初始化时生成searchText把可搜索字段拼在一起。输入变化时只过滤索引字段。没有结果时显示空状态不让列表直接消失。数据量推荐方式100 条以内直接filter1000 条以内预建小索引更大数据分页或后端搜索端侧搜索不是替代后端搜索而是解决“小数据、高频输入”的响应速度问题。interfaceContactItem{id:numbername:stringphone:stringkeyword:string}interfaceContactIndex{id:numbername:stringphone:stringsearchText:string}EntryComponentstruct LocalSearchPage{Statequery:stringprivatecontacts:ContactIndex[][{id:1,name:陈安,phone:13800001111,searchText:陈安 chen an 13800001111},{id:2,name:李北桥,phone:13900002222,searchText:李北桥 li bei qiao 13900002222},{id:3,name:王小满,phone:13700003333,searchText:王小满 wang xiao man 13700003333}]privateresult():ContactIndex[]{consttextthis.query.trim().toLowerCase()if(text.length0){returnthis.contacts}returnthis.contacts.filter((item:ContactIndex)item.searchText.toLowerCase().indexOf(text)0)}build(){Column({space:12}){Text(联系人搜索).fontSize(22).fontWeight(FontWeight.Bold)TextInput({placeholder:搜索姓名、拼音或手机号,text:this.query}).onChange((value:string)this.queryvalue)if(this.result().length0){Text(没有找到匹配联系人).fontSize(14).fontColor(#888888).padding(20)}else{List({space:8}){ForEach(this.result(),(item:ContactIndex){ListItem(){Row(){Column({space:4}){Text(item.name).fontSize(16).fontWeight(FontWeight.Medium)Text(item.phone).fontSize(12).fontColor(#777777)}.alignItems(HorizontalAlign.Start)Blank()Button(拨打).height(30).fontSize(12)}.padding(12).backgroundColor(#FFFFFF).borderRadius(8)}},(item:ContactIndex)item.id.toString())}.layoutWeight(1)}}.padding(16).height(100%).backgroundColor(#F5F7FA)}}把关键代码一段段拆开searchText把姓名、拼音、手机号合并过滤时只查一个字段。result()对空输入直接返回完整列表避免写两套列表 UI。空结果单独展示文案用户知道不是页面坏了。query是唯一输入状态搜索结果不额外保存避免不同步。端侧搜索不要额外存一份结果小数据端侧搜索里query通常就是唯一输入状态搜索结果可以通过result()派生出来。额外保存一份searchResult看起来能少算几次实际很容易和原始数据不同步。示例把姓名、拼音和手机号提前合成searchText输入变化时只过滤这个字段。空输入返回全量联系人无结果时显示空状态用户能明确知道是没有匹配项而不是列表坏了。写在最后数据量继续变大时不要硬扛本地过滤。几百条以内端侧索引很舒服更多数据就要考虑分页、后端搜索或更专业的索引结构。搜索方案要跟数据量匹配不能只看当前 mock 数据很顺。