HarmonyOS ArkTS 搜索请求乱序怎么办输入太快时旧结果为什么会覆盖新结果先把问题说清楚搜索页最烦人的问题不是请求失败而是请求成功了但结果不对。用户输入“红烧牛”最后页面却显示“红”的结果本质就是旧请求晚返回后覆盖了新请求。这个问题表面上看是 UI 小毛病实际上多半是状态边界没有拆清楚。页面里同时有“正在加载”“已有旧数据”“新请求结果”“空状态”“错误状态”如果全部塞进一个布尔值里后面一定会乱。这篇只讲一个可复现问题搜索请求乱序。我会先写一个容易出错的版本再写一个更稳的版本最后给出检查方法。环境和验证目标项说明技术方向HarmonyOS / ArkUI / ArkTS页面模型Stage 模型页面关注点搜索请求乱序验证目标操作顺序变化时页面状态仍然可预测适用场景搜索页、筛选页、列表页、详情页返回刷新错误写法只用一个状态硬撑先看一个很常见的写法。代码短但后面排查很难。Entry Component struct BadCasePage { State loading: boolean false; State keyword: string ; State list: string[] []; State errorText: string ; private async reload() { this.loading true; this.errorText ; try { const result await this.mockRequest(this.keyword); this.list result; } catch (err) { this.errorText 加载失败; this.list []; } this.loading false; } private async mockRequest(keyword: string): Promisestring[] { return new Promise((resolve) { setTimeout(() resolve(keyword ? [keyword 结果] : []), 600); }); } build() { Column({ space: 12 }) { Search({ value: this.keyword, placeholder: 输入关键词 }) .onChange((value: string) { this.keyword value; this.reload(); }) if (this.loading) { Text(加载中) } else if (this.errorText.length 0) { Text(this.errorText) } else if (this.list.length 0) { Text(没有结果) } else { ForEach(this.list, (item: string) { Text(item).fontSize(16) }, (item: string) item) } } .padding(16) } }这段代码能跑但它有几个隐患- 请求慢一点时旧请求可能覆盖新请求- 空状态和加载状态挤在一起页面会闪- 错误后再搜索旧错误文案可能残留- 列表清空太早用户会看到内容突然消失。稳一点的拆法把页面状态拆成模型我的做法是把页面状态拆成明确的模型。不要让 loading、error、list 到处散着改。type PagePhase idle | loading | success | empty | error; class PageStateT { phase: PagePhase idle; data: T[] []; errorText: string ; requestVersion: number 0; startRequest(): number { this.phase loading; this.errorText ; this.requestVersion 1; return this.requestVersion; } applySuccess(version: number, data: T[]) { if (version ! this.requestVersion) { return; } this.data data; this.phase data.length 0 ? success : empty; } applyError(version: number, message: string) { if (version ! this.requestVersion) { return; } this.errorText message; this.phase error; } }这里的关键是 coderequestVersion/code。每次请求开始都拿一个版本号返回时只允许最新版本写回页面。这样输入很快时旧请求就不会覆盖新结果。把模型放回 ArkUI 页面Observed class RecipeSearchState extends PageStatestring {} Entry Component struct BetterCasePage { State keyword: string ; State state: RecipeSearchState new RecipeSearchState(); private async reload() { const version this.state.startRequest(); try { const result await this.mockRequest(this.keyword); this.state.applySuccess(version, result); } catch (err) { this.state.applyError(version, 加载失败请稍后再试); } } private async mockRequest(keyword: string): Promisestring[] { return new Promise((resolve) { setTimeout(() resolve(keyword ? [keyword 结果] : []), 600); }); } Builder buildContent() { if (this.state.phase loading) { LoadingProgress() } else if (this.state.phase error) { Text(this.state.errorText).fontColor(#C0372B) } else if (this.state.phase empty) { Text(没有匹配结果可以换个关键词) } else { ForEach(this.state.data, (item: string) { Text(item).fontSize(16).padding(12) }, (item: string) item) } } build() { Column({ space: 12 }) { Search({ value: this.keyword, placeholder: 输入关键词 }) .onChange((value: string) { this.keyword value; this.reload(); }) this.buildContent() } .padding(16) } }这种写法比一个 loading 变量长一点但排查问题更直接。页面到底是加载中、空结果、成功还是失败看 codephase/code 就够了。案例二防抖只能减少请求不能解决乱序防抖可以减少请求次数但不能保证请求按顺序返回。所以我会把防抖和版本号一起用防抖负责少发请求版本号负责只接收最新结果。class QueryGuard { private currentVersion: number 0; next(): number { this.currentVersion 1; return this.currentVersion; } isLatest(version: number): boolean { return version this.currentVersion; } } Component struct GuardUsagePage { State guard: QueryGuard new QueryGuard(); State text: string ; private async runTask(keyword: string) { const version this.guard.next(); const result await this.remoteSearch(keyword); if (!this.guard.isLatest(version)) { return; } this.text result; } private async remoteSearch(keyword: string): Promisestring { return new Promise((resolve) { setTimeout(() resolve(结果 keyword), 300); }); } }这个小封装适合放到搜索、筛选、分页加载这些位置。只要有“后发请求应该覆盖先发请求”的场景就可以用。怎么验证没有写虚我会按这几步测1. 连续快速输入三个关键词看最后显示的是不是最后一个关键词的结果。2. 输入不存在的关键词看页面是否进入 empty而不是一直 loading。3. 模拟请求失败看错误文案出现后再次搜索是否能恢复。4. 切换筛选条件后看分页和旧列表是否被正确重置。5. 重复进入页面确认没有旧错误、旧空状态残留。如果这几步都过说明这套状态边界是能经得起操作顺序变化的。我会怎么选方案简单页面可以直接用 loading、list、errorText 三个状态不必上来就封装模型。但只要页面出现搜索、防抖、筛选、分页、错误重试我就会把状态收进一个模型里。原因很简单页面越复杂越不能让状态到处散着改。后面如果要复用可以把 codePageState/code 和 codeQueryGuard/code 单独抽出来。不同页面只需要换数据类型和请求方法状态流转还是同一套。
