Search 组件不难用难的是边界。页面上一个搜索框通常会同时承担这些事输入时要拦掉不合法字符粘贴时要清洗一大段内容点搜索时要避免空请求还要把搜索历史排到最新位置。很多问题就是从这里来的所有逻辑都写进onChange。刚开始能跑后面一加中文输入、一加粘贴、一加历史记录就开始出现显示值和提交值不一致。官方 Search 文档里能看到这些能力inputFilter可以做输入过滤onWillInsert/onDidInsert能观察插入前后的内容onWillDelete/onDidDelete能处理删除前后的边界maxLength控制长度SearchController可以处理光标和编辑状态。我的做法不是把它们都堆上而是先把职责分开。这里参考的官方入口主要有三类Search 组件属性和事件、SearchController 的编辑控制、文本输入类组件的输入过滤和插入删除回调。它们的共同点是都在处理输入但位置不一样。inputFilter更靠近“字符能不能进来”onWillInsert更靠近“这一段插入前要不要放行”onSubmit更靠近“这个值能不能进入查询链路”。如果这三个位置不分清页面后面一定难排查。先把输入链路拆成三层我一般按这三层处理层级负责什么不负责什么输入阶段拦明显不该进来的字符比如控制字符、危险符号、超长粘贴不发请求不写历史提交阶段统一trim、空格归一、长度兜底、空关键词拦截不直接改组件内部编辑过程历史阶段去重、排序、限制数量、持久化不参与输入法组合态这样做的好处是很直接的输入框显示什么、最终提交什么、历史记录存什么三件事不会互相抢职责。第一种容易出错的写法把所有规则塞进 onChange下面这种写法看起来省事Search({value:this.keyword,placeholder:搜索菜谱}).onChange((value:string){this.keywordvalue.replace(/[^\u4e00-\u9fa5a-zA-Z0-9]/g,)this.search(this.keyword)this.saveHistory(this.keyword)})问题也很明显输入一个字就可能发一次请求中文输入法还没提交完整就被中途改掉粘贴一段内容时显示值、请求值、历史值可能不是同一个空字符串也可能进入请求或历史历史记录的去重逻辑被输入过程牵着走。搜索框不应该这么累。输入过程只处理输入过程真正发请求应该在提交时做。案例一粘贴复杂内容先拦再统一假设搜索框里已有川菜用户粘贴了一段内容水煮鱼 --辣我希望最终得到的是川菜 水煮鱼 辣这里有两个动作插入前先判断这一段内容会不会把输入框搞乱提交前再统一做一次归一化保证请求值干净。核心逻辑可以先抽成普通函数functionnormalizeKeyword(raw:string):string{return(raw??).normalize(NFKC).replace(/[\u0000-\u001f\u007f]/g, ).replace(/[^\p{ScriptHan}\p{Letter}\p{Number}\s_-]/gu, ).replace(/[-_]{2,}/g, ).replace(/\s/g, ).trim()}functionlimitKeyword(raw:string,limit:number24):string{returnArray.from(normalizeKeyword(raw)).slice(0,limit).join()}functionbuildNextKeyword(currentValue:string,insertValue:string,selectionStart:number,selectionEnd:number):string{constbeforecurrentValue.slice(0,selectionStart)constaftercurrentValue.slice(selectionEnd)returnlimitKeyword(beforeinsertValueafter)}放到 Search 上时onWillInsert更适合做第一层判断onSubmit更适合做最终提交EntryComponentstruct SearchGuardDemo{Statekeyword:stringStateresultText:string还没有提交normalizeKeyword(raw:string):string{return(raw??).normalize(NFKC).replace(/[\u0000-\u001f\u007f]/g, ).replace(/[^\p{ScriptHan}\p{Letter}\p{Number}\s_-]/gu, ).replace(/[-_]{2,}/g, ).replace(/\s/g, ).trim()}commitSearch(raw:string):void{constkeywordArray.from(this.normalizeKeyword(raw)).slice(0,24).join()if(!keyword){this.resultText关键词为空不发请求return}this.keywordkeywordthis.resultText准备搜索${keyword}}build(){Column({space:16}){Search({value:this.keyword,placeholder:搜索菜谱、食材或做法}).maxLength(32).inputFilter([\\u4e00-\\u9fa5a-zA-Z0-9_\\-\\s]).onChange((value:string){this.keywordvalue}).onSubmit((value:string){this.commitSearch(value)})Text(this.resultText).fontSize(15).fontColor(#334155)}.padding(20)}}这里我没有在onChange里请求接口。onChange只同步显示值。提交按钮、键盘回车、搜索按钮触发时再进入commitSearch。案例二搜索历史不要跟着输入过程乱动第二个问题更常见。搜索历史如果在输入阶段就写入用户输入红、红烧、红烧肉历史里可能会出现三条半成品。我会把历史记录放到提交阶段classSearchHistoryStore{privateitems:string[][]push(raw:string):string[]{constkeywordArray.from(raw.trim()).slice(0,24).join()if(!keyword){returnthis.items}this.items[keyword,...this.items.filter((item)item!keyword)].slice(0,8)returnthis.items}list():string[]{return[...this.items]}}页面里只在提交成功后写历史Statekeyword:stringStatehistories:string[][]privatehistoryStore:SearchHistoryStorenewSearchHistoryStore()submitKeyword(raw:string):void{constkeywordArray.from(this.normalizeKeyword(raw)).slice(0,24).join()if(!keyword){return}this.keywordkeywordthis.historiesthis.historyStore.push(keyword)}这时候再看几个边界操作应该发生什么输入空格后提交不发请求不写历史重复提交同一个词移到历史第一位不新增重复项粘贴超长关键词按字符截断不拆半个中文字符粘贴符号和表情先清洗再提交这个规则比“输入一次写一次历史”稳定很多。删除动作也要单独看输入拦截不是只管插入。搜索框还有删除、清空、选中后替换这些动作。如果页面把删除也当成普通onChange来处理容易出现一个现象用户明明只是清空搜索词页面却立刻发了一次“空关键词搜索”列表被刷新成默认状态历史记录还被写了一条空值。我会把删除动作分成两类删除动作页面应该怎么处理用户逐字删除只更新输入框显示值不立即请求用户点清除按钮清空显示值同时把当前结果恢复到默认列表选中一段后替换按插入流程重新清洗不直接复用旧关键词删除后按搜索进入提交阶段空值直接拦截这类规则不一定全部写在 Search 事件里。更稳的方式是让 Search 只发出“值变了”“提交了”“清空了”三个信号页面状态由一个小的 ViewModel 或状态对象统一处理。classSearchStateMachine{keyword:stringsubmitted:stringhistories:string[][]input(value:string):void{this.keywordvalue}clear():void{this.keywordthis.submitted}submit(value:string):boolean{constkeywordSearchKeywordGuard.normalize(value)if(!keyword){returnfalse}this.keywordkeywordthis.submittedkeywordthis.histories[keyword,...this.histories.filter((item)item!keyword)].slice(0,8)returntrue}}这段代码的重点不是“状态机”这个名字而是把三个动作拆开。输入只是输入清空只是清空提交才会进入搜索链路。SearchController 不要太早调用还有一个坑是焦点。页面一进来就想让搜索框自动聚焦或者弹窗打开后立刻把光标放到 Search 里。如果组件还没挂好Controller 调用就可能没效果。我的处理方式是给焦点动作排队页面 ready 之后再执行。比如可以封装一个很薄的调度器classFocusJobQueue{privateready:booleanfalseprivatepending:Array()void[]markReady():void{this.readytrueconstjobsthis.pending.splice(0)jobs.forEach((job)job())}run(job:()void):void{if(this.ready){job()return}this.pending.push(job)}}页面里不要在对象刚创建时就直接调 Controller而是在组件可见、弹窗打开完成、或者页面生命周期进入可交互状态后再处理。这样可以避免“偶尔能聚焦、偶尔不聚焦”的问题。排查时看四个值Search 输入问题不要只盯着一个keyword。我通常会打印四个值值含义出问题时能看出什么rawInput组件刚给出来的原始值输入法、粘贴、删除是否正常进入页面normalizedInput清洗后的显示值过滤规则有没有误伤submittedKeyword真正请求用的值空请求、重复请求、脏字符请求从哪里来historyItems搜索历史是否出现半成品、重复项、空项如果这四个值混成一个变量调试时就只能猜。拆开之后哪一层错了会很快暴露出来。本地验证结果我用独立脚本把两个案例跑了一遍结果如下{caseOne:{input:川菜 pasted noisy text,normalized:川菜 水煮鱼 辣,changed:true,commit:{ok:true,keyword:川菜 水煮鱼 辣,history:[川菜 水煮鱼 辣,川菜,粤菜]}},caseTwo:{emptySubmit:{ok:false,reason:empty_keyword,keyword:,history:[宫保鸡丁]},duplicateSubmit:{ok:true,keyword:粤菜 早茶 套餐,history:[粤菜 早茶 套餐,宫保鸡丁]}}}验证重点不是输出一段漂亮日志而是确认四件事粘贴内容能被清洗空关键词不会进入请求链路重复关键词不会堆历史最终提交值和页面显示值能对上。几种写法怎么选写法适合场景风险只用inputFilter简单字符过滤复杂清洗、历史去重、提交兜底不够只在onChange里处理很轻的本地显示同步容易误伤输入法组合态也容易重复请求inputFilter 提交前归一化搜索、筛选、历史记录需要多写一层封装onWillInsert/onWillDelete做细边界粘贴、删除、特殊输入要精细控制逻辑复杂时要配套测试我更倾向第三种输入阶段轻拦截提交阶段重校验。只有在粘贴规则特别复杂时再把onWillInsert和onWillDelete接进来。可以沉淀成一个小工具搜索框多了以后不要每个页面都复制一遍正则。可以把规则收成一个工具exportclassSearchKeywordGuard{staticnormalize(raw:string,limit:number24):string{returnArray.from((raw??).normalize(NFKC).replace(/[\u0000-\u001f\u007f]/g, ).replace(/[^\p{ScriptHan}\p{Letter}\p{Number}\s_-]/gu, ).replace(/[-_]{2,}/g, ).replace(/\s/g, ).trim()).slice(0,limit).join()}staticvalid(raw:string):boolean{returnSearchKeywordGuard.normalize(raw).length0}}页面里只保留调用constkeywordSearchKeywordGuard.normalize(value)if(!SearchKeywordGuard.valid(keyword)){return}这样以后改规则只改一处。比如要允许/、要限制不能输入纯数字、要把全角空格统一掉都不会散落在多个页面里。以后怎么避免这类问题我的检查顺序是onChange只做显示同步别顺手发请求提交前一定重新归一化不相信输入阶段已经处理干净历史记录只在提交成功后写长度限制按字符处理不要直接按字符串下标硬切粘贴、删除、输入法组合态要单独测Search、TextInput、TextArea 的规则不要混用先看组件支持的事件和属性。搜索框问题表面上是输入问题实际是状态边界问题。把输入、提交、历史三层拆开后面再接联想词、搜索建议、最近搜索、服务端请求节流都不会把一条链路搅成一团。再往后扩展Search 还可以和本地缓存、远程建议词、页面路由参数一起用。原则还是一样Search 组件负责收集输入查询服务负责请求历史仓库负责记录页面只负责把这些状态展示出来。谁负责哪一段先定清楚后面的功能才不会越写越乱。