【寻迹校园 HarmonyOS NEXT 实战 32】受理→隐藏/驳回内容治理为什么必须强制状态顺序本章导读这是“寻迹校园 HarmonyOS NEXT 实战”系列第 32 篇。本文以ModerationService.advance()、ReportService.markHidden()、举报进度页和本地回归测试为证据分析PENDING → IN_REVIEW → RESOLVED/REJECTED的顺序约束以及案件更新成功、内容隐藏失败时的补偿边界。上图为原创生成的治理状态机插画不是应用截图。案件必须先从待受理进入处理中之后才能隐藏内容或驳回举报两个终态不能直接从PENDING跳转。一、为什么“直接隐藏”会破坏治理可信度举报按钮只是提交线索不是最终判决。如果一条记录刚被举报就自动隐藏恶意用户可以通过重复投诉让正常内容消失如果页面允许从待受理直接点击“完成”案件时间线也无法解释谁在什么阶段做了判断。治理流程至少要区分用户已经提交线索案件已经进入核查核查后确认需要隐藏核查后认为不成立并驳回。状态顺序不是为了增加页面步骤而是让内容副作用与审核结论保持一致。二、本章对应的文件映射文件作用common-core/src/main/ets/models/AppContracts.etsModerationStatus与ModerationActionshared-business/src/main/ets/services/ModerationService.ets状态来源校验与隐藏补偿shared-business/src/main/ets/services/ReportService.ets把目标报告标记为HIDDENentry/src/main/ets/pages/ModerationProgressPage.ets时间线、模拟治理按钮和结果摘要entry/src/main/ets/pages/MessagesPage.ets将状态映射为业务消息scripts/local-state-machines.test.mjs越序、隐藏、驳回与可见性断言页面负责展示允许动作Service 负责真正拒绝非法迁移。即使未来新增后台入口状态机规则也不会依赖某一个 ArkUI 按钮。三、四个状态分别表达什么exportenumModerationStatus{PENDINGPENDING,IN_REVIEWIN_REVIEW,RESOLVEDRESOLVED,REJECTEDREJECTED}状态业务含义内容是否隐藏PENDING举报已提交等待受理否IN_REVIEW已受理正在核查否RESOLVED确认违规并完成隐藏是REJECTED未发现违规举报不成立否RESOLVED和REJECTED都是案件终态但对目标报告的副作用完全相反。四、动作枚举比页面文案更稳定当前业务动作是exportenumModerationAction{ACCEPTACCEPT,RESOLVE_HIDERESOLVE_HIDE,REJECTREJECT}页面可以把ACCEPT显示成“模拟管理员受理”以后后台也可以显示成“开始核查”只要动作键不变Service 契约就不会因中文文案调整而失效。五、受理只能发生在 PENDINGACCEPT的来源状态被限制为PENDING。首次受理后案件进入IN_REVIEW结果摘要更新为“案件已受理正在核查内容”。如果当前已经是处理中或终态再次受理会返回“当前案件不能再次受理”。这避免旧页面实例把已处理案件重新覆盖成处理中。当前实现对重复受理返回失败而不是幂等成功。正式 API 可以根据调用场景决定是否返回当前状态但绝不能把终态倒退。六、为什么隐藏必须从 IN_REVIEW 开始RESOLVE_HIDE首先检查if(current.status!ModerationStatus.IN_REVIEW){returnnewOperationResultModerationCase(false,案件受理后才能完成处理);}因此PENDING → RESOLVED被拒绝REJECTED → RESOLVED也被拒绝。用户重复打开旧页面或者自动化错误调用都不能绕过受理阶段。七、驳回也必须从 IN_REVIEW 开始驳回不是“删除举报”而是明确记录核查结论。它同样要求当前状态为IN_REVIEW然后写入状态REJECTED摘要未发现违规原记录保持展示更新时间当前时间。目标 Report 不做隐藏更新所以列表仍然可见。案件和内容状态分别表达“举报处理结束”和“内容继续展示”。八、案件状态和内容状态是两个聚合ModerationCase记录治理过程ItemReport记录内容是否可展示。确认违规时需要协调两个 Repository案件进入RESOLVED目标报告进入HIDDEN。如果只更新案件公开列表仍展示违规内容如果只隐藏报告案件又没有可解释结论。两者必须联动但不应合并成一个枚举。九、当前代码为什么先保存案件再隐藏内容advance()先修改案件状态和摘要写入ModerationRepository然后调用awaitreportService.markHidden(saved.targetReportId);顺序写入便于单机实现但它不是原子事务。第一步成功、第二步失败时系统会短暂出现“案件已完成、内容仍可见”的不一致窗口。十、隐藏失败后的回退逻辑当前 Service 捕获markHidden()异常后把案件退回IN_REVIEWsaved.statusModerationStatus.IN_REVIEW;saved.outcomeSummary案件已受理内容隐藏失败请重试;awaitthis.repository.update(saved,this.context);然后返回successfalse和更新后的案件。页面会重新加载列表用户看到“处理中”及可重试提示而不是错误地显示“已完成”。上图展示顺序写入的成功路径与失败回退。回退降低了不一致暴露时间但两次 Repository 更新仍不等于数据库事务。十一、补偿本身也可能失败如果内容隐藏失败随后把案件退回IN_REVIEW的写入也失败外层catch会返回“案件状态保存失败请稍后重试”。此时真实状态需要重新读取不能根据最后一条提示猜测。完整补偿系统应记录操作 ID、已完成步骤和可重试任务。当前单机实现只有同步回退没有持久化补偿队列、重试次数或告警面板。十二、markHidden 还有一个静默风险ReportRepository.updateStatus()在设备数据库中执行条件更新但当前代码没有检查受影响行数本地回退数组找不到目标时也不会抛错。因此如果报告在受理期间被删除markHidden()可能没有真正更新任何记录却仍然正常返回。提交阶段虽验证目标存在但“提交到处理”之间仍可能发生变化。正式实现应检查更新行数找不到目标时返回明确的NOT_FOUND并决定案件应标为“目标已移除”还是进入人工复核。十三、举报进度页如何只展示合法动作ModerationProgressPage根据状态渲染按钮PENDING只显示“模拟管理员受理”IN_REVIEW显示“模拟驳回”和“完成并隐藏内容”RESOLVED / REJECTED不再显示处理按钮。页面还使用processingId防止同一时刻重复点击。它属于交互保护Service 的来源状态检查才是最终保护。十四、为什么页面必须写明“模拟治理人员”当前进度页顶部明确提示这是单机比赛演示按钮模拟治理人员操作不代表真实平台审核。同一设备既能提交举报又能点击受理和隐藏只能证明状态机、页面刷新和 Repository 联动。它不能证明真实运营账号、角色权限、服务端审核、申诉或多设备同步。十五、消息文案必须跟随权威状态消息中心把四个状态映射为“待受理、处理中、已完成、未通过”并展示outcomeSummary。隐藏失败回退后消息应重新读取案件并显示处理中而不是保留页面本地的“已完成”。项目通过共享dataRevision触发页面重新加载。页面不手工修改多个角标或卡片避免重启后和 Repository 冲突。十六、本地测试覆盖了哪些迁移当前测试实际断言首次提交得到PENDINGPENDING直接执行RESOLVE_HIDE失败越序失败后仍为PENDINGACCEPT成功进入IN_REVIEWRESOLVE_HIDE成功后案件为RESOLVED目标 Report 为HIDDEN另一案件经受理后驳回为REJECTED驳回后的目标 Report 仍为OPEN。powershell-ExecutionPolicy Bypass-File.\scripts\test-local-state-machines.ps12026-08-23 本地执行通过。失败补偿的真实 RelationalStore 故障注入、受影响行数、重启恢复和多客户端并发仍未覆盖。十七、状态迁移表比 if/else 更适合评审当前状态动作下一状态Report 副作用允许PENDINGACCEPTIN_REVIEW无是PENDINGRESOLVE_HIDE-无否PENDINGREJECT-无否IN_REVIEWRESOLVE_HIDERESOLVEDHIDDEN是IN_REVIEWREJECTREJECTED保持可见是终态任意处理动作-无否新增“申诉中”“证据补充中”时应先更新这张表再修改代码、页面和测试。十八、正式服务端的事务设计联网版可以在同一事务中锁定案件和报告校验操作者拥有治理权限按版本号读取案件校验当前状态允许动作更新案件状态和审计字段若为隐藏检查目标报告存在并更新状态写入 outbox 事件提交事务后异步生成通知。如果内容存储和治理服务不在同一数据库则需要 Saga、幂等命令和补偿任务不能用客户端两次请求假装原子完成。十九、错误信息应描述已完成到哪一步“处理失败”无法指导恢复。更有价值的结果包括案件尚未受理不能完成处理案件已受理但内容隐藏失败可重试内容已经被其他流程移除请刷新案件状态已被其他治理人员更新隐藏成功消息通知稍后送达。错误文案本身也是状态机契约不能和真实副作用相矛盾。二十、工程复盘终态必须由业务事实定义RESOLVED不应只表示“管理员点了完成”而应表示目标内容已经达到对应治理结果。在当前语义中就是案件结论已保存且 Report 已进入HIDDEN。若隐藏没有发生回退到IN_REVIEW比继续显示完成更诚实。同样REJECTED表示核查后未发现违规内容保持展示。它不是技术错误也不是用户提交失败。把业务驳回、系统故障和待处理混在一个状态会让消息、统计和申诉全部失去可信来源。二十一、本文小结治理状态顺序的核心是把“收到举报”“开始核查”和“形成结论”拆成不同事实。当前“寻迹校园”已经在 Service 层拒绝越序动作隐藏成功时联动 Report隐藏异常时把案件回退到IN_REVIEW并通过本地测试验证主要迁移。但顺序写入仍不是事务回退也可能失败updateStatus()尚未检查受影响行数真实治理身份、并发版本锁、持久化补偿和申诉审计仍是正式版工作。系列导航第 32 篇 / 共 50 篇。上一篇《举报去重与案件复用》下一篇《为什么用业务消息替代陌生人聊天》。