文章定位审核流复盘推荐标签Spring Boot、Vue.js、内容审核摘要用故障复盘方式讲清三角色投稿审核闭环重点覆盖状态机、并发审核、审计记录与高风险测试。01一次看似正常的发布为什么会留下隐患项目资料将系统划分为注册用户、审核员和管理员三类角色。注册用户负责编辑并提交文章审核员给出审核结论管理员维护用户、轮播图、通知公告、新闻资讯并管理已经进入发布环节的内容。这个分工看起来清楚但只要状态与权限没有写进后端页面上隐藏按钮并不能阻止越权调用。复盘场景假设两名审核员同时打开同一篇待审文章A 点击“通过”B 随后点击“驳回”。如果系统只做普通更新后提交的结果会覆盖前一次审核作者看到的状态与审核记录可能互相矛盾。因此本文不把“用户管理、文章管理、新闻资讯”逐个罗列而是沿着一篇文章的生命周期检查角色、接口、数据表和测试是否形成闭环。发布文章页面用户完成标题、分类和正文录入后提交审核02先画清状态再写接口原项目资料中存在“文章信息”和“发布文章”等数据对象并包含文章提交与审核测试。为了避免多个布尔字段组合出非法状态工程实现更适合使用单一状态字段。下面的状态机属于基于原功能的重构建议并非对原始源码的断言。当前状态允许动作下一状态执行角色DRAFT 草稿编辑、删除、提交PENDING_REVIEW作者PENDING_REVIEW 待审通过、驳回APPROVED / REJECTED审核员REJECTED 已驳回查看意见、修改、再次提交PENDING_REVIEW作者APPROVED 已通过发布、退回PUBLISHED / REJECTED管理员PUBLISHED 已发布下线、查看、评论OFFLINE管理员 / 读者JAVApublic void review(Long articleId, ReviewCommand cmd, Long reviewerId) {Article article articleRepository.findByIdForUpdate(articleId).orElseThrow(() - new BizException(文章不存在));if (article.getStatus() ! PENDING_REVIEW) {throw new BizException(该文章已被处理请刷新列表);}if (!cmd.isPassed() isBlank(cmd.getOpinion())) {throw new BizException(驳回时必须填写原因);}article.changeStatus(cmd.isPassed() ? APPROVED : REJECTED);reviewLogRepository.save(ReviewLog.of(article, reviewerId, cmd));}这里的关键不是代码写法而是三条约束审核对象必须处于待审状态驳回必须有原因审核结论必须写入独立历史记录。03角色权限要落在服务端不要只藏菜单资料中的角色功能可以整理成“对象权限 动作权限”两层。注册用户只能操作自己的草稿审核员可以读取待审队列但不应修改作者正文管理员可以发布审核通过的文章却不应绕过审核直接把草稿设为公开。动作作者审核员管理员后端校验重点编辑正文仅本人草稿禁止可下线后协助修订author_id status提交审核允许禁止可代提交但需留痕字段完整性、内容长度给出审核结论查看结果允许监督/复核role current_status公开发布禁止禁止允许status 必须为 APPROVED管理轮播图与公告禁止禁止允许管理员权限、操作日志审核员处理发布文章审核结果应与审核意见一起保存04数据库不要只保存“最后一次结果”原始材料列出了注册用户、审核员用户、文章信息、发布文章和轮播图等表。若把所有信息都堆在文章表中后续很难回答“谁在什么时候驳回过、驳回原因是什么、文章修改了几次”。更稳妥的拆分方式如下文章主表保存当前版本、作者、分类、当前状态和最新更新时间。文章版本表每次提交审核时固化标题、正文和附件快照避免审核期间正文变化。审核记录表保存审核人、结论、意见、时间和对应版本号。发布记录表保存发布人、发布时间、下线时间及下线原因。轮播图与新闻资讯表与文章审核流解耦避免运营内容修改影响投稿数据。SQLCREATE UNIQUE INDEX uk_article_review_onceON article_review(article_id, article_version, reviewer_id);-- 乐观锁更新时必须带上旧版本号UPDATE articleSET status :targetStatus, version version 1WHERE id :id AND status :expectedStatus AND version :version;05把原测试用例改造成“高风险场景清单”项目资料已经覆盖用户注册、登录、新闻资讯查看、文章发布和文章审核。相比只验证“按钮能不能点”更有价值的是把异常用例放到发布链路中。风险场景期望结果为什么重要标题为空或正文过短拒绝提交并保留草稿避免无效内容进入审核队列驳回但未填写原因阻止提交审核结果作者需要可执行的修改意见两名审核员同时处理仅一人成功另一人收到状态已变化提示避免结果覆盖审核通过后作者继续编辑生成新版本并重新审核保证公开内容与审核内容一致网络中断重复点击提交接口幂等不产生两条待审记录避免重复任务06页面设计不同角色看到的重点应完全不同作者端应该突出“草稿—待审—驳回—已发布”的进度和审核意见审核员端应该突出待审数量、提交时间、分类和风险提示管理员端则需要全局搜索、下线处理、轮播图、公告和新闻资讯管理。三个端如果只是换了菜单名称实际使用效率会很低。管理员后台内容发布之外还承担用户、公告和运营位管理07这类项目最值得继续补的三项能力版本对比审核员可以查看本次提交与上一次驳回版本的差异而不是重新通读全文。审核队列分配按分类、提交时间或负载将任务分配给审核员减少重复抢单。审计与申诉对删除、下线、封禁等敏感操作保存日志并为作者提供申诉入口。点赞❤关注私信博主免费领取项目源码谢谢如需其他项目或毕设源码可进主页看下往期的毕设资源分享哦希望对您有帮助