【寻迹校园 HarmonyOS NEXT 实战 31】举报去重怎么做同一记录的重复投诉不应制造多条处理中案件本章导读这是“寻迹校园 HarmonyOS NEXT 实战”系列第 31 篇。本文结合ModerationReportPage、ModerationService.submit()、ModerationRepository.findByReportId()与本地状态机测试拆解举报原因、敏感信息拦截、重复案件回执和数据库唯一约束之间的边界。上图为原创生成的举报去重流程插画不是应用截图。同一个targetReportId再次提交时当前单机实现返回已有案件而不是继续生成新的待处理记录。一、重复举报为什么不是“多存一条就行”在失物招领场景中用户可能因为网络迟缓、按钮重复点击、返回页面后再次进入连续提交同一条内容举报。如果每次提交都生成案件会出现三个直接问题消息中心同时显示多条相同进度治理人员可能对同一内容做出不同结论一条记录隐藏后其他案件仍停留在“处理中”案件统计把重复操作误算成多起问题用户不知道应该跟踪哪个案件编号。因此举报提交不是简单的INSERT。在创建新案件之前必须先回答“这条目标记录是否已有可复用案件”。二、本文对应的真实文件本章结论来自以下项目文件而不是抽象的后台系统设想层级文件责任ArkUI 页面entry/src/main/ets/pages/ModerationReportPage.ets选择原因、输入说明、展示提交状态Serviceshared-business/src/main/ets/services/ModerationService.ets校验、查重、创建案件、返回业务结果Repositoryshared-business/src/main/ets/repositories/ModerationRepository.etsRelationalStore 与本地回退数据读写Modelcommon-core/src/main/ets/models/AppContracts.ets原因、状态、动作和案件模型测试scripts/local-state-machines.test.mjs验证重复提交返回同一个案件 ID页面只维护输入草稿态。是否允许举报、是否重复以及返回哪个案件统一由 Service 和 Repository 决定。三、先固定五类举报原因ModerationService当前提供五个枚举值枚举页面文案主要用途PRIVACY泄露隐私公开内容包含联系方式、精确地址等FALSE_INFO虚假信息内容明显失实或误导ILLEGAL违法违规涉及违法违规信息INAPPROPRIATE_MEDIA图片或内容不适媒体或描述不适合展示OTHER其他问题无法归入前四类的线索固定枚举比自由填写原因更容易统计、筛选和制定处理规则。补充说明仍可保留细节但它不能替代结构化原因。四、页面禁用按钮不能代替 Service 校验ModerationReportPage会显示加载、提交中和错误状态但真正的业务门禁在submit()中执行。即使未来从深链、消息页或其他入口发起请求也必须经过相同校验。constresult:OperationResultModerationCaseawaitmoderationService.submit(this.reportId,this.selectedReason,this.note);页面成功后跳转举报进度页失败时展示result.userMessage。它不会自行创建案件 ID也不会直接操作数据库。五、补充说明为什么限制为 200 字当前 Service 对说明执行trim()并拒绝超过 200 字的内容。举报表单的目的不是开放第二个评论区而是补充判断所需的最小事实。过长文本会增加三个风险用户粘贴整段聊天或个人信息、消息卡片难以摘要、未来服务端审核和日志存储成本上升。200 字是当前产品约束不是 HarmonyOS 平台限制正式上线后仍应根据真实治理流程调整。六、敏感信息要在进入 Repository 前拦截当前实现阻止手机号、身份证和“密码”等典型敏感内容privatecontainsSensitiveContent(value:string):boolean{returnvalue.includes(密码)||value.includes(身份证)||/1[3-9][0-9]{9}/.test(value);}这条规则只能覆盖典型误填不是完整的数据防泄漏系统。用户仍可能通过空格、谐音或图片绕过。因此正式产品还需要字段最小化、图片治理、服务端规则和人工复核不能把一条正则描述成“彻底消除隐私泄露”。七、为什么禁止举报当前设备发布的记录Service 在创建案件前读取目标ItemReport并检查isUserCreated。当前单机演示把“当前设备创建”作为近似身份边界自有记录应走编辑、撤回或删除而不是进入举报流程。这不是正式账号权限。设备标记不能证明真实作者身份也无法阻止多设备场景下的伪造。联网版应由服务端根据登录主体和记录所有者判断而不是信任客户端布尔值。八、查重的核心是 targetReportId当前 Repository 提供asyncfindByReportId(reportId:string):PromiseModerationCase|undefined{returnthis.findOne(target_report_id,reportId.trim(),this.context);}ModerationService.submit()在插入前调用它。查到已有案件时直接返回成功和原案件编号if(existing){returnnewOperationResultModerationCase(true,该记录已有举报案件编号${existing.id},existing);}对用户而言这是幂等式回执重复操作不会制造新案件同时仍能进入原进度页继续查看。九、当前实现比大纲更严格终态案件也会被复用一个容易被忽略的真实细节是findByReportId()没有限制PENDING或IN_REVIEW。只要该报告存在任何历史案件包括RESOLVED或REJECTED再次举报都会返回旧案件。这适合“同一条不可变内容只处理一次”的单机演示却不一定适合正式产品。如果发布者修改了内容或者出现新的违规事实用户可能需要重新举报。正式版可以把唯一范围改为“目标报告版本 活跃状态”或者引入contentVersion同一版本只允许一个活跃案件新版本允许创建新案件同时保留历史审计。十、当前数据库没有 target_report_id 唯一索引moderation_case表只把id声明为主键target_report_id是普通非空列。这意味着“先查询、再插入”在单线程顺序执行中有效但不是数据库级唯一保证。两个并发请求可能同时查到不存在然后分别插入不同的CASE-*。本地时间戳 ID 也不是跨设备全局一致的业务约束。正式服务端至少应选择一种方案对活跃案件建立条件唯一索引在事务内执行查重和插入使用reportId contentVersion作为幂等键接口接收客户端操作 ID并返回已创建结果对冲突错误转换为“返回已有案件”而不是通用失败。上图对比两种保护层级上方应用层先查后写仍可能被并发穿透下方把事务和唯一约束放入权威数据库冲突请求只返回已有案件不再产生第二条记录。十一、举报 ID 为什么不能由页面生成当前 Service 使用CASE-${Date.now()}创建单机案件编号。页面只接收保存后的saved.id并跳转。如果页面先生成 ID再分别写列表、消息和详情重试时很容易产生多个编号。正式联网版应由服务端或统一 ID 服务生成稳定标识并把幂等结果作为响应返回。十二、重复提交应该返回成功还是失败这里选择返回successtrue因为用户的目标“确保这条记录已进入举报流程”已经满足。提示语明确告诉用户已有案件而不是伪装成本次新建成功。如果返回通用失败用户可能继续点击如果新建第二条又会污染治理队列。幂等成功与重复创建不同前者复用同一个资源后者制造额外副作用。十三、消息中心如何消费复用结果提交成功后页面进入ModerationProgressPage消息中心通过moderationService.listCases()读取案件。因为重复操作没有新增记录消息页也只显示一条治理状态卡片。卡片使用案件标题、短编号、当前状态和outcomeSummary并提供“查看进度”按钮。它展示业务状态不提供自由输入因此不会把重复举报演变成重复对话线程。十四、本地测试如何证明去重项目测试按以下顺序执行插入目标拾得记录以PRIVACY提交首次举报断言状态为PENDING再以OTHER提交重复举报断言第二次仍返回成功断言第二次返回的案件 ID 等于首次 ID继续验证越序隐藏被拒绝。powershell-ExecutionPolicy Bypass-File.\scripts\test-local-state-machines.ps12026-08-23 本地实际运行通过。这个结果证明生产 Service 的本地回退路径遵守规则不等于数据库并发唯一索引或多设备重复请求已经验证。十五、异常回执要区分四类原因用户看到的失败至少应区分场景当前回执原因非法请选择举报原因说明过长或含敏感信息指向具体字段记录不存在或属于当前设备说明目标不可举报Repository 异常举报提交失败请稍后重试把所有问题都写成“提交失败”会诱发重复操作也不利于定位是输入、权限、目标状态还是存储故障。十六、正式版还要处理报告被编辑和删除举报提交后目标报告可能被编辑、撤回或删除。案件不能只保存标题否则治理人员无法知道当时举报的是哪个版本。更完整的案件应保存内容版本、必要的脱敏快照、举报时状态和证据摘要。快照必须控制最小字段并设置保留期限不能因为审计需要就永久复制全部个人信息。十七、工程验收清单上线前可按以下不变量验收同一目标版本最多一个活跃案件重复请求返回相同案件 ID请求重试不会增加消息卡片数量终态案件是否允许重开有明确产品规则自有记录由服务端身份判断敏感说明不会写入日志并发冲突由唯一约束或事务处理被编辑或删除后仍保留可解释的最小审计证据返回旧案件时明确告诉用户“已有举报”。十八、工程复盘查重规则必须包含时间维度“按reportId查重”只是第一版答案。真正稳定的唯一语义通常是“目标内容的某个版本在某个活跃窗口内只允许一个治理案件”。缺少内容版本历史驳回会阻塞对新内容的举报缺少活跃状态终态案件无法按规则重开缺少数据库约束并发仍能绕过 Service 查询。因此实现前应先写唯一性表唯一键由哪些字段组成哪些状态算活跃内容修改是否递增版本案件关闭后多久允许新建重复请求返回哪条记录。把这些问题留给页面按钮处理会让多入口和多设备行为不一致。十九、本文小结举报去重的目标不是少存几行数据而是让同一治理事实只有一个权威进度。当前“寻迹校园”已经在 Service 层校验原因、长度、敏感内容、自有记录并在插入前按targetReportId复用已有案件本地测试证明重复提交返回相同 ID。但当前表结构没有目标唯一索引查询也会复用终态案件。数据库并发、内容版本、真实身份、跨设备幂等和服务端审计仍未实现不能从单机顺序测试外推。系列导航第 31 篇 / 共 50 篇。上一篇《双方确认后才能结案》下一篇《受理、隐藏与驳回的强制状态顺序》。