Spring Boot实现App信息审核后台：状态机与并发控制实战解析

简介：这是App信息管理系统完整工程，涵盖App信息的查看与审核两大业务模块，面向需要后台审核功能开发实战的开发者与在校学生，适合用于毕业设计、课程设计、工程实训及日常练手。项目资源共176个文件，核心代码以Java、JSP为主，包含33个Java源文件和20个JSP动态页面，辅以19个JS脚本、13个XML配置、13个CSS样式表，另附20个APK测试安装包与相关设计文档，压缩包总大小约95.68MB，目录结构清晰，便于按模块查阅。已有46人浏览学习。将工程导入开发环境即可复现运行，也可在此基础上扩展审核流程、权限控制等功能；内置测试包与界面截图可快速验证效果，设计报告亦可参考借鉴。若运行中遇到问题，可联系作者获得技术支持，整体质量可靠，适合需要快速复现同类型应用系统的人群。

1. 这个 App 信息管理系统到底治什么：一份 zip 里的完整工程

这周拆了一个典型的内部后台资源包，名字很直白：App信息管理系统功能，查看app信息以及审核app信息.zip。里面没有微服务那堆花活，就是一套能直接跑的「App 上架审核后台」：后端统一管理 App 名称、包名、版本号、图标、下载链接、开发者资料，前端给管理员一张列表和详情页，点「通过」或「驳回」后审核结果写回库，状态全程可查。适合两类人：一是要交毕业设计或给公司搭内部运营平台的开发，二是想学一个完整状态机业务如何落地的刚入行同事。先说一句反直觉的结论：这类系统真正的坑不在列表查询，而在审核状态流转的并发约束，以及压缩包解压后的路径乱码问题，这也是我把这个资源包拆开讲透的原因。

2. 从 zip 解压到表结构设计：先把数据流和状态机立住

2.1 压缩包解压后的目录：先分清哪些是代码、哪些是配置

拿到手先解压。这个 zip 我习惯用 7-Zip 解压到纯英文目录，比如D:\apps\app-ms，因为后面部署时中文路径会导致静态资源和图标路径一串连锁问题，第 4 章会专门讲。

:: 在 Windows CMD 下解压 unzip -d D:/apps App信息管理系统功能，查看app信息以及审核app信息.zip tree /F D:\apps

解压后典型的工程结构是这样的：

D:\apps\app-ms ├─backend │ ├─src │ │ └─main │ │ ├─java │ │ └─resources │ ├─pom.xml ├─frontend │ ├─static │ └─index.html ├─sql │ └─init.sql └─docs └─部署说明.md

先说逻辑说明：backend是后台服务端工程，负责登录、列表、详情、审核这几组接口；frontend是管理端页面，通常是一套静态页面或轻量 Vue 工程，浏览器内直接调用接口；sql目录下是初始化脚本，这是整个资源最先要看的文件；docs里会有部署说明，内容包括 JDK 版本、MySQL 版本、端口号和默认账号。如果拿到的包没有前端目录，那就是把页面以templates形式塞进后端了，部署步骤更少，本质一样。

参数说明方面，unzip -d D:/apps的-d指定解压目录，能避免把文件四散在根目录。部署说明里如果写了server.port=8080而你本机 8080 被占，可以先不用管，等会启动时用--server.port=8081参数覆盖，省得先去改配置文件重启一轮。

这个包的 SQL 脚本我建议不要用图形化工具一条条复制，直接命令行执行：

mysql -u root -p -e "create database app_manage character set utf8mb4 collate utf8mb4_general_ci;" mysql -u root -p app_manage < D:\apps\app-ms\sql\init.sql

这里character set utf8mb4是关键参数，App 图标路径和权限描述里很可能出现 emoji 或特殊符号，用默认的 utf8 会直接报错或落库后变问号。utf8mb4 才是 MySQL 里真正完整的 UTF-8 编码，collate 用不到的时候不用管，保持默认即可。

2.2 三张核心表与 App 审核状态机：为什么必须拆成两张业务表

看 init.sql 时不用被里面七八张表吓到，真正吃透核心逻辑只需要关注三张表：管理员表、App 信息表、审核记录表。我把最关键的建表语句摘出来，这份资源和绝大多数同类工程的表结构基本一致：

CREATE TABLE `sys_user` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `username` VARCHAR(50) NOT NULL, `password` VARCHAR(100) NOT NULL, `role` TINYINT NOT NULL DEFAULT 1 COMMENT '1管理员 2审核员', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `app_info` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `app_name` VARCHAR(200) NOT NULL, `package_name` VARCHAR(200), `version_name` VARCHAR(50), `version_code` INT, `icon_path` VARCHAR(255), `download_url` VARCHAR(500), `developer_id` INT, `permission_desc` TEXT, `status` TINYINT NOT NULL DEFAULT 0, `submit_time` DATETIME, `audit_time` DATETIME, `audit_user_id` INT, `audit_remark` VARCHAR(500), `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, KEY `idx_status` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `app_audit_record` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `app_id` INT NOT NULL, `audit_user_id` INT, `action` VARCHAR(10) COMMENT 'APPROVE/REJECT', `remark` VARCHAR(500), `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, KEY `idx_app_id` (`app_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

逻辑说明：app_info表里同时存在status、audit_time、audit_user_id、audit_remark这四个审核相关字段，是为了让列表页直接展示「是谁在什么时候给了什么结论」，不用每次审核都去关联查询记录表。真正需要明细追踪时才去查app_audit_record。这两张表的分工是：app_info存当前最新状态，app_audit_record存每一次操作历史。当前状态和审计日志分开放，是我个人比较坚持的建模习惯——如果只留一张日志表，列表页的查询性能会随审核次数增长而恶化；如果只留最新状态，运营扯皮时拿不出历史证据，后悔药都没得吃。

status字段是这个系统的状态机核心，我用一张表说明取值含义：

参数说明：version_code是整数类型，用于内部版本号比较，version_name是展示给用户看的字符串，这两个字段在 App 上架场景几乎成对出现，别合并成一个。permission_desc用TEXT而非VARCHAR，是因为权限声明可能超过 255 字符，这是新手最容易踩的表结构小坑。

这套状态机里最反直觉的一条设计是：驳回后不能直接改状态为 1，必须先让开发者「重新提交」，这个中间动作在工程里实际对应的是置status = 0还是status = 1取决于业务规则。我见过不少二次开发的同事把「重新提交」直接做成自动通过，等于绕过了审核流程，这是状态机里最容易翻车的地方。

3. 查看 App 信息列表：登录鉴权、分页查询与搜索的实操写法

3.1 管理员登录与 Token 鉴权：先解决「谁在看」的问题

整个管理后台第一步是登录。这套工程的后端用的是一套很传统但足够稳定的方案：用户密码先做加密，登录成功后生成一个随机 Token 存到缓存，并回传给前端，前端后续请求都带这个 Token。核心代码长这样：

@PostMapping("/api/login") public Result login(@RequestBody LoginDTO dto) { // 这里用 MD5 只是演示老工程的兼容写法，新项目请换成 BCrypt String md5Pwd = DigestUtils.md5DigestAsHex(dto.getPassword().getBytes(StandardCharsets.UTF_8)); LambdaQueryWrapper<SysUser> qw = new LambdaQueryWrapper<>(); qw.eq(SysUser::getUsername, dto.getUsername()) .eq(SysUser::getPassword, md5Pwd); SysUser user = userMapper.selectOne(qw); if (user == null) { return Result.fail("用户名或密码错误"); } String token = UUID.randomUUID().toString().replace("-", ""); // 2 小时后过期，避免长期占用内存 redisTemplate.opsForValue().set("login_token:" + token, user.getId(), 2, TimeUnit.HOURS); return Result.ok(token); }

逻辑说明：这段登录逻辑的核心是拿用户名和加密后密码查表，命中则签发 Token。selectOne要求最多返回一条记录，所以不要用selectList然后再判断size() == 1，多此一举。UUID生成的是 32 位无横线字符串，长度适中，用作登录态标识已经够用，做不过度设计。

这里关键参数有两个：2, TimeUnit.HOURS是 Token 有效期，内部管理后台我一般设置 2 到 8 小时，太短审核员频繁掉线，太长有账号盗用风险；缓存 key 里的login_token:前缀，是为了后续清理缓存时方便按前缀批删，也给排查问题时一个明显的标识。

提示：不要把整个 SysUser 对象塞进 Token 或 Redis value，只存user.getId()就够，需要用角色时再查一次库。这样可以避免改了用户角色后旧 Token 仍带着老权限。

3.2 列表查询：分页、状态过滤与多维搜索

「查看 App 信息」这个功能在管理端的长相就是一张表格：App 图标、名称、包名、版本号、提交时间、当前状态、操作按钮。看起来简单，但因为列表要支撑多种筛选，SQL 会比想象中啰嗦。常见的写法是基于 MyBatis-Plus 的 QueryWrapper，或者直接用一段手写 SQL：

SELECT id, app_name, package_name, version_name, version_code, icon_path, download_url, status, submit_time FROM app_info WHERE (app_name LIKE CONCAT('%', #{keyword}, '%') OR package_name LIKE CONCAT('%', #{keyword}, '%')) AND status = #{status} AND submit_time BETWEEN #{startTime} AND #{endTime} ORDER BY submit_time DESC LIMIT #{offset}, #{pageSize}

逻辑说明：这段 SQL 一次解决了三件大事。app_name的模糊匹配处理的是用户搜「抖音」这类名称；package_name的模糊匹配处理的是运营拿着报错日志里的com.xxx.yyy来反查；submit_time的时间区间则解决「今天待审核的有多少」这种问题。三个条件之间是 AND 关系，所以如果某个条件前端没传，后端要做动态拼接，不能直接查空值。

参数说明：LIMIT的offset是起始行数，pageSize是每页条数。前端传页码page和每页条数size，后端换算offset = (page - 1) * size。这里最容易出错的是前端从 1 开始计数，而后端从 0 开始，不换算就直接查会把第一页的数据丢一半。用 MyBatis-Plus 的话，直接传Page<T>对象就不会有这个换算问题，所以我个人更推荐把这套手写 SQL 只在多表统计时用。

对于查询性能，这个表在status字段上一定要建索引，因为列表页默认第一步永远是WHERE status = 1（待审核）。在submit_time上加索引收益不高，因为时间筛选总是跟状态条件混用；真正要做时间维度统计时，可以单独给submit_time加索引，但别一上来就加，索引也是写成本。

这个列表接口还有一层容易被忽略的业务逻辑：数据库里存的是icon_path，返回给前端时必须拼成完整可访问的 URL，比如存的是/files/icons/1001.png，接口返回时要补全为http://服务器IP:8080/files/icons/1001.png。如果原包是直接存全路径，部署换机器后这批数据就全挂了，这是我在多个项目里反复踩过的坑，建议返回实体时统一加一个虚拟字段icon_url，不让前端去拼。

4. 审核 App 信息：状态流转、审核记录与三个高频排查点（避坑篇）

4.1 审核接口的状态约束：用条件更新对抗并发重复操作

管理端最重要的按钮是「通过」和「驳回」。这两个操作看似只是把status从 1 改成 2 或 3，但如果两个审核员先后点了同一款 App 的通过按钮，系统必须保证只有一个能成功。如果不做约束，第二次操作会把第一次的审核时间和审核人悄悄覆盖，这是审核类系统的黑匣子事故。

工程里的审核服务，核心逻辑是这样的：

@Transactional(rollbackFor = Exception.class) public void audit(AppAuditDTO dto) { // 第一步：再次检查当前状态是否为待审核 AppInfo app = appInfoMapper.selectById(dto.getAppId()); if (app == null || app.getStatus() != 1) { throw new BizException("该 App 不在待审核状态，请刷新列表"); } int newStatus = "APPROVE".equals(dto.getAction()) ? 2 : 3; int updated = appInfoMapper.update(null, new UpdateWrapper<AppInfo>() .eq("id", dto.getAppId()) .eq("status", 1) // 关键条件：只有当前状态是 1 才允许更新成功 .set("status", newStatus) .set("audit_time", new Date()) .set("audit_user_id", dto.getOperatorId()) .set("audit_remark", dto.getRemark())); if (updated != 1) { throw new BizException("操作失败，该 App 已被其他人处理"); } // 第二步：写一条审核记录，用于留痕 AppAuditRecord record = new AppAuditRecord(); record.setAppId(dto.getAppId()); record.setAuditUserId(dto.getOperatorId()); record.setAction(dto.getAction()); record.setRemark(dto.getRemark()); auditRecordMapper.insert(record); }

逻辑说明：这段代码最有价值的地方不是@Transactional，而是更新语句里那个.eq("status", 1)条件。MySQL 在执行这条 UPDATE 时会对命中行加锁，第二个请求进来时，因为状态已经不是 1，影响行数为 0，updated != 1直接触发异常，事务回滚，第二个人就不会带着旧数据把第一次的审核结果覆盖掉。这个方法本质上是一种乐观锁防重，但没有增加任何版本号字段，利用了业务状态本身来做并发约束，比select后if判断再update安全得多。

参数说明：dto.getAction()只有APPROVE和REJECT两个值，前端传参时必须做白名单校验，不能用if (action != null)这种宽松判断，否则任何一个脏字符串都会落进app_audit_record.action字段，后面统计通过率时永远对不上。业务异常BizException要在全局异常处理器里捕获并返回给前端，不要把异常栈直接抛给用户。

关键参数rollbackFor = Exception.class表示只要抛出任何异常就回滚，这里包含更新app_info和插入app_audit_record两步，必须绑定在一个事务里，否则会出现「内容改了但记录没插上」这种让人抓狂的中间状态。

4.2 审核完成后的联动操作：缓存、首页统计与通知

审核落库不算完，一个合格的信息管理系统还要让整个后台的数据同步更新。工程里通常要处理三个联动点：

// 1. 清理列表页缓存，避免用户看到旧状态 redisTemplate.delete("app_info_page:" + dto.getPageKey()); // 2. 重新统计待审核数量，刷新顶部红点 String countKey = "app_count:pending"; redisTemplate.delete(countKey); // 3. 给开发者发送站内信通知，异步执行 asyncNotifyDeveloper(dto.getAppId(), dto.getAction(), dto.getRemark());

逻辑说明：列表页如果做了缓存，审核成功的下一步必须清掉对应的缓存 key。清缓存要按前缀精确删除，不要动不动flushdb把整个 Redis 干空，会让在线用户集体掉线。待审核数量这个统计值，很多工程会缓存起来，这个 key 的失效策略我习惯用「修改即删、查询时重建」，而不是设置固定过期时间，因为统计值靠主动失效一致性最强。

asyncNotifyDeveloper是异步线程池执行的通知方法，里面可能发站内信、短信或邮件，但无论哪种都不能放在审核事务里同步执行，否则第三方接口慢的时候，前端审核按钮会一直转圈，体验极差。

与业务相关的审核记录，在写入时有一个值得注意的细节：remark是审核员填写的原始文字，要限制长度在 500 字符以内，防止有人贴一大段日志把表撑爆。前端在录入时就要做字数统计，后端再校验一次，双保险。

4.3 三个高频问题排查：一次完整的踩坑记录

这一节是整个资源里最值钱的部分，因为这包里的代码逻辑大概是能跑的，但部署在不同机器上会遇到三类高频翻车现场。每一条我都按「现象 → 原因 → 解决」给到可操作的步骤。

现象 1：审核接口返回成功，列表页还是「待审核」状态，刷新也没变化。

原因是列表查询走了 Redis 缓存，而审核方法只更新了数据库，忘记删缓存 key。这种问题最容易出现在审核成功后的 5 分钟内，用户刷新页面看到旧数据，会误以为系统坏了。解决办法是在 4.2 联动段里检查两步：确认缓存工具类是同一个 Redis 数据库，确认删除 key 时用的前缀和查询时写入的前缀完全一致——我见过最离谱的一次是查询时 key 写成app_info_page_1，删除时写成app_info_page:1，下划线改成了冒号，缓存死活删不掉。这种问题要在本地复现就要 Debug 到 Redis 客户端里keys app_info_page*看实际 key 名称。

现象 2：解压后路径带中文，图标加载不出来，或 Spring Boot 启动就报找不到静态资源。

原因在 2.1 已经埋了伏笔：zip 包解压后，如果目标目录是D:\资源\app-ms，Windows 下 Tomcat 处理静态资源路径时编码不一致，icon_path里存的中文文件名也会变成%FF%一类乱码。解决方法是强制约定解压到纯英文路径，而不是去改 Tomcat 配置。如果你已经解压到中文目录，最简单有效的处理是剪切整个目录到D:\apps\app-ms重新启动，不要试图在application.yml里配什么URIEncoding=UTF-8来处理文件名乱码，那解决不了 jar 包内部静态资源映射的问题。

现象 3：前端页面能打开，所有接口返回 401 未登录，包括登录接口自己。

原因基本可以确定是拦截器配置把所有路径都拦截了。乍一看很奇怪，登录接口返回 401，说明整个鉴权拦截器生效范围是/**，把/api/login也圈进去了。解决办法很简单，Spring 拦截器注册处精确配好「放行白名单」：

registry.addInterceptor(loginInterceptor) .addPathPatterns("/api/**") // 只拦截后台接口 .excludePathPatterns("/api/login") .excludePathPatterns("/files/**"); // 图标和安装包要放行

逻辑说明：.addPathPatterns("/api/**")限制了拦截范围，不会误伤静态页面资源；/files/**放行是因为 App 图标和安装包通常都挂在/files目录下，如果被鉴权拦截器挡住，列表页的图标会全部裂开。如果原工程里没有这个排除项，你只需要在配置类里把这行追加上去，重启后问题自然消失。这个排错路径，基本能覆盖 80% 管理后台的 401 问题。

5. 把完整流程跑通验证，再谈工程复用的三个习惯

5.1 十分钟快速自检：从启动到审核成功一次通过

拿到源码后不要急着改代码，先按「黑盒验证」的思路把整条跑通一遍，确认授权包是完整可运行的。我的习惯动作是四步走。

第一步，启动后端服务，看控制台日志有没有打印Started Application in 6.312 seconds；第二步，不登录直接请求GET /api/app/list，预期返回 401，确认鉴权是开着的；第三步，调登录接口拿 Token，用带 Token 的请求查列表，确认能查到初始化脚本里内置的那几条 App 数据；第四步，构造一条/api/app/audit请求，通过后查表看status是否变成 2，以及app_audit_record是否多了一条记录。

这四步走完，这个资源的核心功能就算验完货了。如果第四步卡住，回看第 4 章排查表，大概率不是代码问题，而是缓存或路径问题。

5.2 复用这个工程的三个纪律

这套包我前后拆过两次，一次是做毕业设计移植，一次是给公司搭内部应用商店后台。两次改造踩了不少坑，总结出三条纪律，写在这里当提醒。

第一，状态值不要散落在业务代码里当魔法数字。把status的 0、1、2、3 抽成一个AppStatus常量类，命名像AppStatus.PENDING_REVIEW、AppStatus.APPROVED，比在if (app.getStatus() == 2)里写死数字要可靠得多——否则后续加一个「已上架」状态，你会找不到哪里漏改。

第二，任何审核操作，先把应用详情快照存入审核记录表里。app_audit_record表除了 action 和 remark，有条件就加一列snapshot_json，把审核那一刻的 App 名称、版本、权限声明原样存进去。等某天下线追责时，快照能证明审核员看到的确实是你所看到的，没有中间被篡改的争议。

第三，所有审核时间统一以数据库时间为准。用 MySQL 的NOW()还是 Java 的new Date()要全项目统一，千万别一半接口用数据库时间、一半接口用应用服务器时间。两个服务器时钟差 30 秒，运营在纠纷帖里发现审核时间对不上，会认为系统伪造记录，这口锅比代码 bug 更难解释。

说来有点不好意思，我第一次部署这个包时，就是栽在第 4 章第三个现象上，登录接口一直 401，折腾到凌晨两点，最后发现是拦截器把登录也拦了。从那以后我做这类后台项目，任何链路都强制先走一遍登录-列表-审核的闭环验证，再开始业务改动。这套流程每次都能把死角照出来。希望帮到你，下次拿到这个 zip，照着这份笔记走，能少踩一个是一个。

本文还有配套的精品资源，点击获取