在图片检索页面里，输入框里出现了四个字，不代表用户已经决定检索这四个字。更不用说中文输入法正在组词、删除候选词或者替换整句时，onChange 可能连续给出许多中间文本。将每次变化都当作一次正式检索，会产生一个不显眼的问题：页面上看到的新关键词，可能配着上一轮的图片结果。本文把问题限定在业务提交边界：用 ArkUI Search 显示输入内容，用显式提交动作建立一次查询，再用本地模拟检索函数演示结果归属。它不调用未经核实的图像模型接口，也不把生成的界面图称为实机日志。目标不是提升算法召回率，而是让“输入了什么、提交了什么、结果属于谁”三件事彼此说得清楚。## 一、先为输入框定一条不能越过的界线演示项目取名 QueryFence，页面文件位于 entry/src/main/ets/pages/SearchPage.ets。给这一轮示例固定任务号 QF-110，用户准备查询“雨后站台”。示例数据预设三条图片标签：雨后站台、候车雨伞、末班列车。提交一次以后，页面状态从 IDLE 经过 SEARCHING 到 READY，最终显示三条结果。开发界面和手机截图中的次数、文字都按这份样例固定，不代表真实调用量。这里需要拆开两个值：draft 是编辑框中的实时文本，submittedQuery 是用户主动提交、已经进入处理流程的关键词。还有一个序号 requestSerial，它并非服务器返回的请求 ID，而是页面内部用来识别过期异步完成通知的自增整数。因为这三个量的含义不同，不能偷懒用同一个 keyword 顶替。以中文输入为例，候选词改变时可以更新 draft，但不改 submittedQuery，更不刷新结果列表。若用户改写输入却没有再次提交，就在结果区明确写“结果对应上次提交”。这种做法会让一些人觉得少了即时反馈，却保留了数据出处。想做实时联想，也应把联想建议与正式检索结果分别存储；不能把建议接口当成最终搜索。## 二、把检索结果的身份留在数据模型里### 1. 不把图片 URL 当作唯一业务状态下面这段代码要解决的是结果归属问题。业务卡片保存自己的 id、title 和关键词，不在模型层混入搜索框的当前字符。样例中的 tags 由演示数据写死，用来模拟匹配；没有任何端侧视觉推理过程。arktsinterface PhotoHit { id: string; title: string; tags: string;}const FIXTURE_HITS: PhotoHit[] = [ { id: 'QF-P01', title: '雨后站台', tags: '雨后站台 铁轨' }, { id: 'QF-P02', title: '候车雨伞', tags: '雨后站台 候车' }, { id: 'QF-P03', title: '末班列车', tags: '雨后站台 列车' }];````id` 是业务项的稳定键，即便后面补上真实图片 URI，也不该用数组下标去识别被点选的照片。示例故意只有三条，是为了清楚观察输入和提交的关系，不暗示算法会从图库里恰好找出三张。正式产品还要处理图库授权、索引构建、结果分页、损坏文件、空索引与隐私提示；这里都不假装已经实现。配图出现的图片缩略画面是视觉示意，不是模型输出。### 2. 让提交动作拥有一次快照第二段代码解决最容易犯的错误：在 `onChange` 里发出异步请求。`Search` 在这里承担输入和提交控件角色，`onChange` 只写入草稿，`onSubmit` 才调用业务方法。状态由 `@State` 驱动页面更新。arkts@Entry@Componentstruct SearchPage { @State draft: string = ‘雨后站台’; @State submittedQuery: string = ‘’; @State searchState: string = ‘IDLE’; @State hits: PhotoHit[] = []; private requestSerial: number = 0; build() { Column({ space: 12 }) { Text(‘QueryFence · 文搜图’) Search({ value: this.draft, placeholder: ‘描述想找的图片’ }) .onChange((value: string) => { this.draft = value; }) .onSubmit((value: string) => { this.commitQuery(value); }) Text(提交词：${this.submittedQuery || '尚未提交'}) Text(状态：${this.searchState} · 结果：${this.hits.length}) }.padding(16) }}这是一段突出机制的页面片段，后续两个方法应合并进入同一组件后再编译。`onSubmit` 传入的是本次提交值，不能在异步结束时再去读可能已改变的 `draft`。如果用户在提交期间继续输入，新草稿不会悄悄改写旧结果的标签。这里不写任何猜测的 SDK 小版本，实际工程应以自己编译目标对应的 Search 组件签名为准。![](https://i-blog.csdnimg.cn/direct/990b55b7f7a94d2c98cbab8753ba20d0.png)## 三、比节流更重要的是拒绝过期完成即便坚持手动提交，用户也可能短时间连按两次搜索；处理层可能先返回第二次，再返回第一次。只禁止按钮点击不一定可靠，因为请求可能由快捷键、导航恢复或其他入口触发。需要有一个与页面状态配套的完成条件。第三段代码负责规范化输入、拒绝空白提交，并为每次提交分配序号。为了避免冒充真实端侧 AI，`localSearchFixture` 仅匹配固定字符串；换成真实服务以后，序号门禁仍保留。日志文字只是预期的调试格式，应在实际工程中按回调打印，不能把文章示例当作性能记录。arktsprivate async commitQuery(raw: string): Promise { const word = raw.trim().replace(/\s+/g, ’ '); if (word.length === 0) { this.searchState = ‘EMPTY_QUERY’; return; } const serial = ++this.requestSerial; this.submittedQuery = word; this.searchState = ‘SEARCHING’; try { const rows = await Promise.resolve(FIXTURE_HITS.filter( (item: PhotoHit) => item.tags.includes(word) )); if (serial !== this.requestSerial) { return; } this.hits = rows; this.searchState = ‘READY’; console.info([QueryFence] task=QF-110 request=${serial} state=READY count=${rows.length}); } catch (err) { if (serial === this.requestSerial) { this.searchState = ‘FAILED’; } }}```这里 requestSerial 的比较是页面自己的最后写入获胜规则；它并没有中止底层计算，也不保证服务端不继续计费。生产端如支持取消，应另外释放网络连接或任务句柄。如果错误发生于较老请求，也不应把当前有效检索的状态覆盖成 FAILED。另外，空白输入不应沿用上一次的成功提示，否则用户会误以为检索已成功完成。## 四、看运行结果，不看输入动画是否热闹演示图固定为一个有意简单的页面：上方输入词“雨后站台”，下方蓝色状态条写 READY，三条结果按序显示；任务号 QF-110 明确标注。示例时刻 10:58，手机顶部 Wi‑Fi、5G、信号及电量只是演示状态栏，不来自真实设备。搜索按钮文字使用“提交检索”。对这张画面，更值得观察的是“已提交：雨后站台”和“输入草稿：雨后站台”分别出现，而不是图片缩略图有多真实。可按下面的手工测试路径核对：先逐字改变草稿，在提交前检查结果仍是旧值；再提交一次，确认三条固定样例对应已提交关键词；立即输入另一个词但不提交，检查旧结果旁出现“上次提交”的提示；最后快速提交两次，观察只有最新序号允许改写结果。预期日志至少包含 task=QF-110、request=1、state=READY、count=3。如果看到的是“输入发生变化就不断新增 request”，说明业务边界被放错了位置。如果日志是 READY 但结果区没有三条，则应检查 hits 是否真正更新，以及视图中是否错误读取了另外一个收藏数组。不要用模型生成的图片证明这些断言成立；测试要以 HiLog 实际采样为依据。## 五、页面销毁、失败重试和真正的文搜图这种小 Demo 很容易漏掉页面退出。用户打开详情又返回，先前异步查询可能仍在完成。可在页面离开时增加一次 requestSerial，使旧完成回调失去改写权；下一次进入页面，再根据业务决定保留已提交结果还是重新拉取。这里没有订阅外部事件，因此也没有需要虚构的监听器注销代码。若将来引入网络、图片解码或 Worker，必须在对应生命周期中补充显式取消与释放。失败重试也不能直接复制 draft。重试应该复用失败那次的 submittedQuery，否则用户在等待期间改了输入，点击“重试”就会悄悄变成新任务。另一方面，当前示例的 Promise 立即完成，无法模拟网络乱序；想验证过期结果屏障，应在测试桩里人为控制两个 Promise 的完成顺序，并为每一轮记录序号，而不是在正文声称已经测出了耗时或者成功率。如果项目下一步接入系统相册检索能力，应将“关键词获取 → 检索任务 → 结果图卡”的接口分层。前端的 Search 不负责图片语义理解；本地固定 tags 也不等于端侧语义模型。对敏感相册内容，应先核对图库访问权限和索引策略，再决定是否持久化查询词。最终原则很简单：编辑过程可频繁变化，正式查询必须有明确的提交时刻，异步结果必须有可以核验的归属。## 六、资料和复现边界本文参考华为 HarmonyOS 开发者文档中的 ArkUI Search 组件、文本输入事件及 ArkTS 状态管理相关资料：- Search 组件参考：https://developer.huawei.com/consumer/cn/doc/harmonyos-references/ts-basic-components-search- 输入控件与键盘开发说明：https://developer.huawei.com/consumer/cn/doc/HarmonyOS-Guides/arkts-customize-keyboard- ArkTS 声明式 UI 开发：https://developer.huawei.com/consumer/en/doc/harmonyos-guides-V2/ui-ts-developing-intro-0000001544455257-V2接口示例以可核对的普通 ArkUI 事件和 ArkTS 语法为限。未声明任何未经验证的系统检索 Kit、模型版本或实际设备能力。本稿是可以据此实现的工程设计说明，不等于已经在 DevEco Studio 通过编译、真机检索或获得性能数据。