HarmonyOS RDB 多条件查询怎么写：分类、关键词和排序条件为什么不要直接拼 SQL 字符串

HarmonyOS RDB 多条件查询怎么写分类、关键词和排序条件为什么不要直接拼 SQL 字符串先把问题说清楚本地 RDB 查询一开始只有一个关键词直接拼字符串好像也能跑。等后面加分类、收藏、最近浏览、排序字段SQL 就会变得很难维护。这个问题表面上看是 UI 小毛病实际上多半是状态边界没有拆清楚。页面里同时有“正在加载”“已有旧数据”“新请求结果”“空状态”“错误状态”如果全部塞进一个布尔值里后面一定会乱。这篇只讲一个可复现问题RDB 多条件查询。我会先写一个容易出错的版本再写一个更稳的版本最后给出检查方法。环境和验证目标项说明技术方向HarmonyOS / ArkUI / ArkTS页面模型Stage 模型页面关注点RDB 多条件查询验证目标操作顺序变化时页面状态仍然可预测适用场景搜索页、筛选页、列表页、详情页返回刷新错误写法只用一个状态硬撑先看一个很常见的写法。代码短但后面排查很难。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 就够了。案例二排序字段必须白名单where 条件可以用参数数组但排序字段不能直接接收外部输入。我会用白名单把排序类型映射成固定字段避免把未知字符串塞进 SQL。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 单独抽出来。不同页面只需要换数据类型和请求方法状态流转还是同一套。