Spring Boot大学生兼职管理系统：角色权限与状态机设计实践

我刚拿到这套 Spring Boot 大学生兼职信息管理系统源码的时候，第一反应其实是“又一个常规 CRUD”。但真正动手把学生端、企业端、管理员三套角色跑通，再顺着报名状态从待审核走到已完成的流程调试一遍之后，我改观了。所谓“管理信息系统”能不能成为一份合格的毕业设计，看的不是功能名称有多新，而是业务闭环是否完整、角色权限是否合理、边界有没有控制住。

市面上以“计算机毕业设计源码66946”这类编号流传的工程包很多，里面最常见的通病是：表结构放了一堆，代码只覆盖新增和查询，状态流转没有约束，连登录都有绕过风险。而这篇里我想梳理的，是我在复现和扩展这套系统时真正沉淀下来的东西——从角色拆解、数据库设计到几个关键接口的实现细节和答辩准备，按我在实际调试里的思路讲。

1. 大学生兼职场景里的真实断点，以及选题的“恰到好处”

1.1 兼职信息不是缺“量”，是缺“可控的流动”

只要在学校里待过一阵，就会明白兼职信息的原生状态其实相当原始：QQ群公告、兼职群转发、食堂门口的传单、同学推荐。兼职本身并不少，真正乱的是这些信息没有统一的发布入口，也没有状态管理。

一个岗位发在微信群里，上午被刷上去，下午就沉底了；同学们报名靠私聊接龙，到底有没有录上、录上了几点去、工资找谁结，全靠雇主口头约定。对学校或者管理方来说，企业资质没人核，过期岗位没人下架，出了问题连追溯记录都费劲。

大学生兼职信息管理系统解决的，不是“找到更多兼职”，而是把已经存在的兼职信息流程化。做需求分析时一定要讲清这一点，因为大多数答辩老师不关心你代码里写了多少行，他们关心你有没有看清场景里的痛点。从产品逻辑来看，这条业务线的核心是“信息可控”：谁来发、谁审核、谁能报名、状态怎么流转，每一步都需要被系统约束。

1.2 为什么这个项目 scale 对毕设来说刚好合适

选毕设最忌讳两个方向：一是太小，一张表一个页面就结束，工作量撑不起论文；二是太大，又是分布式又是消息队列，自己一个人加班三个月也调不通。大学生兼职管理系统的边界刚好卡在中间。

它具备了毕设需要的绝大多数知识点：用户认证与权限区分、岗位发布、报名条件校验、状态回写、文件上传、数据统计。业务主体不复杂，没有太多乱七八糟的领域规则；操作链条却足够长，足够支撑起数据库设计里五六张核心表外加若干业务表。你要想做得深入一些，可以在通知模块加站内信，也可以在企业端加录用流程；要照顾开发周期，纯后端加上表格展示也能完整收尾。这种可伸缩的空间，比项目本身的新颖程度更难得。

但这套选题也并不是没有门槛，最大的门槛在于很多人容易把“业务表”做成“日志表”。如果只是把学生、兼职、报名三条数据堆上去，那整个系统看起来就是一个带界面的数据录入工具。所以我在后文会花一整节单独说数据库里那张“报名记录表”的状态机设计——这部分想明白了，整个项目的层次感就出来了。

2. 按角色拆解功能地图：学生、企业、管理后台各自掌握什么样的边界

2.1 三端边界是权限设计的前提，不是页面拼接的游戏

很多毕设系统在登录后只对按钮做隐藏，后端接口全都不设防；一个学生登录后，手动调接口就能把报名的状态改成录用。这种接口在设计阶段就必须被堵住，而堵住的前提，是把角色的边界想清楚。

大学生兼职系统的参与者通常分成三类。第一类是学生用户，核心动作是浏览、检索、报名和查看结果；第二类是企业用户或者兼职发布方，核心动作是发布岗位、审核报名、确认是否到岗；第三类是管理员，负责对全站信息做审核和治理。

这里有个很常见的产品问题：企业注册后能不能立刻发布岗位？如果一律要求平台先审核注册主体，那么演示“发布即展示”会很麻烦；如果完全不审核，又会显得系统没有治理能力。比较常见的做法是：企业注册后可以登录、可以编辑资料，但发布的第一条岗位必须等管理员后台通过，状态字段从“待审核”翻成“已上架”之后才会在前台被学生看到。这一个开关就能让系统显得专业很多。

下表是我在梳理功能清单时常用的边界矩阵，也可以直接拿去做论文里的用例图素材：

2.2 先画角色，再画功能，最后才写代码

按角色拆功能的好处在于，你可以顺着一个角色的操作路径把每一条线走通，而不是顺着页面菜单一个个画框。

我习惯先写三份角色场景小故事：比如“学生小李看到一条奶茶店兼职，投递报名，企业端当天晚上把状态改成已录用，小李到岗后由企业在系统里标记完成，学生可以对这次兼职进行评价”。这份小故事会直接转化成接口依赖链：查询岗位、插入报名记录、修改报名状态、校验兼职是否处于报名期、写评价时校验是否已完成。一条线走完，后端接口边界就清晰了。

相反，如果一开始就从“学生管理、岗位管理、企业管理、评价管理”这种模块列表出发，很容易做成四个孤岛，模块之间没有行为关系，写到最后也只能应付最简单的增删改查。

我在源码里看到的工程结构也印证了这一点。它的 service 包明显是按照实体去拆的，但 controller 层的路径设计是围绕动作展开的，例如报名相关的接口会同时用到 job 表和 apply_record 表。如果你做二次开发，不建议把逻辑塞进 controller 里，而是把“报名动作”看成用户和企业两个角色之间的一次交互事务，在 service 层去编排数据变化。数据一致性留到 service 层处理，controller 只负责参数接收和结果包装。

3. Spring Boot 技术骨架和选型原因，别用版本给自己挖坑

3.1 框架组合凭什么不用最“新”的

技术选型时，很多同学会下意识点开 Spring Initializr，直接选最新稳定版。但站在毕设工程和二次开发源码的角度，版本不是越大越好。我这个项目用的组合是 Spring Boot 2.7.x + MyBatis-Plus + MySQL 8.0 + JDK 1.8，没有选 Spring Boot 3.x。

原因是这几层刚好卡在生态舒适区：JDK 8 是所有实验室机器最常见的环境；Spring Boot 2.7.x 对 JDK 8 的支持最稳定；MyBatis-Plus 的多数文档和主流示例也都是基于这个组合写的。实际打包部署时，这条链路的出错概率极小。如果你非要选 Spring Boot 3.0 以上，就要面对 JDK 17、Jakarta EE 命名空间、部分 starter 包不再自动装配的问题。网上能搜到那种“springboot版本太高”的求助帖，基本都是代码抄着低版本教程、环境却选择了高版本的结果。

我看这套工程时没有直接用一套很新的代码去重写，也是基于这个考虑。一个毕设项目的目标是让人在两周内能复现、能讲清楚、能跑通整个流程。用技术生态里最成熟的版本，比追逐最新 dependency 靠谱得多。

3.2 MyBatis-Plus、MySQL、JWT还是 Sa-Token

ORM 选型上，MyBatis-Plus 比原生 MyBatis 更省事，也比 JPA 更容易向同学解释。毕业设计里你肯定要展示代码，Mapper 接口直接继承 BaseMapper，然后 custom SQL 写在 XML 里，既有框架的自动 CRUD，又保留了手写复杂 SQL 的灵活性，答辩时能说的点很多。

单表查询用 MyBatis-Plus 的 LambdaQueryWrapper 也就够了：

java复制LambdaQueryWrapper<ApplyRecord> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(ApplyRecord::getDeleted, 0)
       .eq(ApplyRecord::getStudentId, userId)
       .orderByDesc(ApplyRecord::getCreateTime);
Page<ApplyRecord> page = new Page<>(current, size);
applyRecordMapper.selectPage(page, wrapper);

权限控制方面，我见过不少工程直接用拦截器判断 session 里的 loginUser，然后把 userId 塞到 session 里，跨域调接口时各种取不到。比较稳的一版是用 JWT 把 userId 和角色标识签进 token，每个接口从请求头发过来的 Authorization 中解析登录人信息。JWT 的优点是后端天然无状态，部署时不需要考虑 session 复制；但对毕设场景来说它也有一个需要处理的问题：token 一旦签发，服务端无法主动让它失效。所以我会把用户的封禁状态也放在 token 载荷里一起校验，或者强制带上用户权限版本号，否则管理员封了账号，用户手里的老 token 依然能访问。

如果你不想手写 JWT，也可以直接用 Sa-Token。它自带的注解很容易实现角色权限控制，内置踢人下线，对中小项目来说确实省力。但用 Sa-Token 也有一个答辩风险：老师如果没接触过这个框架，会追问它的实现原理。如果你只是会调用注解，就很容易答不上来。JWT 虽然代码多一点，但原理简单，容易被问住的地方少，这一点在答辩现场很值钱。

3.3 前端展示选 Vue 还是模板引擎

取决于你这套源码的主要交付形式。项目编号里带“源码”的一般会把前后端一起提供。常见有两种：

一种是 Spring Boot 只做后端接口，前端单独用 Vue 2/3 + Element-Plus 搭后台管理系统。这种做法的展示效果最好，页面结构接近真实企业应用，但需要额外解决跨域、路由守卫和打包后静态资源部署问题。

另一种是 Spring Boot 直接渲染 Thymeleaf 页面，加 Bootstrap 做样式。好处是整体部署只有一个进程，不用启动前后端两个服务，答辩现场关掉 IDE 再重启也能很快恢复。缺点是交互体验相对笨重，下拉联动、模态框都要写不少 jQuery。

我对纯后端能力不算特别强、又想稳妥展示的同学的建议是：前端页面可以用 Thymeleaf 或直接加载本地静态 HTML，只要保证接口调用通畅即可。真正决定评分的是你在答辩时演示出来的业务闭环，而不是页面动画。反过来，如果项目时间充裕，Vue 3 写一个简洁版前端，对面试作品集也是一个加分项。

4. 数据库设计：用关系模型给一次兼职报名装上“状态机”

4.1 核心表不是三张，是“五加一”

很多第一版设计，只建了学生表、岗位表、报名表。跑起来之后马上发现三个问题：企业信息没有独立载体，岗位只能塞一个发布者字符串；用户收藏岗位没地方存放；管理员审核岗位的时候没有审计痕迹。所以在复刻这套系统时，我至少会保留这些核心表：

要注意 sys_user 和学生信息的关系。学生不一定需要单独表，因为学生只在注册时填一次基本信息，没有太多高频变化的属性；但如果学校要求抓取学号和学院，那么把 student_profile 拆出来会更好。核心原则是不要把所有角色塞成一张 user 表里的一个 role 字段就结束，因为企业的业务字段差异很大，把 company 字段全放在 sys_user 里会让表变得很胖。

4.2 报名记录的状态码设计，是这篇设计的灵魂

我在第 1 部分说过，这个系统不能做成简单录入工具，区分的核心就在 apply_record.status 字段上。它记录的不只是“报名是否存在”，而是“一份报名当前处在什么状态”。我用代码里的状态码作为参考，整理了一套规则：

• 0：学生已提交报名，企业可见
• 1：企业已录取，学生需确认或到岗
• 2：到岗完成，订单完结
• 3：学生或企业取消/拒绝，流程终止
• 4：管理员违规介入，强制终止

这套状态机的关键不是数字，而是转换限制。比如报名状态已经从 0 变成 1，学生就不能再点击“取消报名”，而是需要走“取消录用”的申请流程；状态到 2 后允许评价，状态为 0 时企业如果误点了录取，管理员可以重置。

我在另一些更细的版本里见过把 1 拆成“已录取未确认”“已确认未到岗”两档的，会更符合现实，但也会让前端页面的按钮组合变多。对毕设来说，0/1/2/3 四个状态已经足够讲清楚状态模式。关键是你要在论文里画一张状态转换图，并把每一个状态变更对应的触发接口写清楚，老师一眼就觉得你的业务是严谨的。

4.3 数据库层面的防重与一致性约束

状态如果只靠 Java 代码判断，很容易出并发问题。学生手快点了两次报名，两个请求同时打到后端，代码里都先查了一遍“是否存在报名”，发现没有，于是各插了一条记录，最终出现两条报名。解决这个问题的方式有两个层面：

第一层是数据库加唯一索引，让同一个学生对同一个岗位只能有一份报名：

sql复制ALTER TABLE apply_record
  ADD UNIQUE KEY uk_student_job (student_id, job_id);

第二层是更新状态时使用乐观的 SQL 条件，而不是先查询再更新。

java复制int rows = applyRecordMapper.update(null,
    new LambdaUpdateWrapper<ApplyRecord>()
        .eq(ApplyRecord::getId, recordId)
        .eq(ApplyRecord::getStatus, 0)
        .set(ApplyRecord::getStatus, 1));
if (rows == 0) {
    throw new BusinessException("当前报名状态已变化，请刷新后重试");
}

这种“UPDATE ... WHERE status = 0”的方式能确保只有当前状态符合预期的记录才能被修改，逻辑上比“查出来再判断再 update”安全得多。我在很多生产项目里也一直沿用这个套路，对毕设系统来说完全够用。

数据冗余方面，岗位表里通常会保存一个 applied_count，每次新增报名时原子加一；但如果你没有缓存中间件，要保证这个累加字段别直接用“读出来 +1 再写回去”的方式，否则并发场景会丢数。更稳妥的方式是：

sql复制UPDATE job_position
SET applied_count = applied_count + 1
WHERE id = #{jobId}

在这套系统里，我建议岗位已报名人数直接实时 count 报名表即可，因为整体数据量不会太大，没必要放冗余计数引来一致性麻烦。

5. 四个关键功能点的实现细节，以及调试现场最容易翻车的几个位置

5.1 登录和权限拦截器，放行规则比 token 解析更值得检查

如果用 JWT，网上很多教程会告诉你写一个“JWT 拦截器”，然后在 config 里注册 addInterceptors。但如果不小心把拦截器作用到所有路径上，就连登录页的静态资源也会被拦下来，启动后访问登录接口直接 401。放行规则一定要包含登录注册接口、验证码接口和资源路径。

我实际用到的思想是：用 preHandle 解析 header，拿到 token 后把 userId 放进 request attribute，后续 controller 可以取；对于加权限的路径，再做一次角色判断。示例代码如下：

java复制@Component
public class JwtAuthInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        if ("OPTIONS".equalsIgnoreCase(request.getMethod())) {
            return true;
        }
        String auth = request.getHeader("Authorization");
        if (auth == null || !auth.startsWith("Bearer ")) {
            response.setStatus(401);
            return false;
        }
        String token = auth.substring(7);
        Claims claims = JwtUtil.parseToken(token);
        if (claims == null) {
            response.setStatus(401);
            return false;
        }
        request.setAttribute("loginUserId", Integer.valueOf(claims.get("userId").toString()));
        request.setAttribute("loginUserRole", claims.get("role").toString());
        return true;
    }
}

我见过一个最隐蔽的问题：后端做的是前后端分离，前端用 axios 带 token，但网关或者打包后的 nginx 配置没把 header 透传过去，接口在本地调试正常，一旦打包部署就登录失效。排查时先看浏览器 Network 面板，再确认 Authorization 有没有到后端，不要把问题直接推给 JWT。

5.2 岗位图片上传与访问路径配置

岗位发布往往需要上传图片或企业营业执照。源码里常见的问题是：文件保存到了本地磁盘，但数据库只存了一个“images/xxx.jpg”这样的相对路径，前端 <img> 标签访问不到，因为后端没有把静态资源目录映射出来。

Spring Boot 中需要显式配置“虚拟路径映射”：

java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
    @Value("${file.upload-path}")
    private String uploadPath;

    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        // 磁盘绝对路径透出到 /upload/** 虚拟路径
        registry.addResourceHandler("/upload/**")
                .addResourceLocations("file:" + uploadPath + File.separator);
    }
}

同时要注意文件重命名。直接用用户上传的原文件名非常容易造成路径穿越或覆盖，正确做法是生成 UUID 文件名，再用原始后缀做白名单校验。

java复制String ext = FilenameUtils.getExtension(file.getOriginalFilename());
if (!Arrays.asList("jpg", "jpeg", "png", "gif", "pdf").contains(ext.toLowerCase())) {
    throw new BusinessException("不支持的文件类型");
}
String savedName = UUID.randomUUID().toString().replace("-", "") + "." + ext;

5.3 报名按钮的“重复提交”，接口要做幂等

表面上页面按钮在提交后会被禁用，实际上用户完全可以用脚本或连续点击触发多个请求。最典型的场景就是第 4 节提到的重复报名。这里如果只靠前端 disable 按钮，数据库里很可能留下重复记录。接口层要做一次“防重”判断，利用数据库唯一索引捕获异常，捕获到 DuplicateKeyException 后返回“您已报名该岗位”，而不是把堆栈抛给用户。

页面层还能再加一层：报名后立刻把按钮变成“已报名”，在后端返回失败时再恢复。这种多层防重复的做法在论文的“系统实现”小节里也能写得很漂亮。

5.4 通知模块：别为了“高级感”盲目引消息队列

我在查设计资料时看到不少衍生版会往项目里塞 RabbitMQ、ActiveMQ 或 Flowable 工作流，理由是“报名后要通知企业”。这里必须冷静一点。如果只是一个报名动作需要写一条站内信，或者写一条通知记录，数据库里一张通知表完全能承担，完全不值得引入消息中间件。

我更推荐用 Spring 自带的事件监听机制。学生提交报名后，发布一个事件，监听器把通知记录插入 notice 表，顺便更新内存里对应企业的未读数量。这样代码解耦，又不增加额外依赖。如果某些教程工程非要集成 Flowable 或 ActiveMQ，你要考虑付出的调试成本远大于收益。毕设考察的是你把某个问题讲透，而不是把“听说过的技术名词”全部堆上去。

6. 部署、演示与答辩：源码之外还能展示出工程感的三个抓手

6.1 用脚本和环境配置把“复活成本”降到最低

很多同学答辩那天，打开电脑发现 IDEA 里报了个端口被占用，或者 MySQL 密码不对，现场就开始修环境，观感极差。我经验是准备一份可执行的启动清单：

• 数据库连接配置放到 application-dev.yml，用户名密码单独抽出来，不要写死在 Java 代码里。
• 把初始化 SQL 文件放在项目根目录的 doc/sql 下，建库、示例数据一步到位。
• 前端如果打包好，放进 Spring Boot 的 static 或 templates 目录，这样启动一个 Java 进程就能看到完整页面。
• 演示前先跑一遍冒烟测试：注册一个测试学生、企业登录、发布岗位、报名、审核、完成。整个链路通了再关机。

这套系统编号 66946 的源码包我在初始化时也遇到过导入问题，大多是 Lombok 版本与 IDE 版本不兼容导致 getter/setter 找不到。遇到这种问题先去 pom.xml 里看 Lombok 的版本，不要急着把整个工程删掉重建。

6.2 加一张不可见的审计日志表，工程感立刻上一个台阶

管理后台不要只增删改查，我强烈建议加一张操作日志表或者至少用 Spring AOP 切面记录关键操作。因为兼职平台最怕的是信息违规、虚假岗位、恶意报名，管理员一旦介入，必须能回答出“谁在什么时间做了什么操作”。

在代码里写切面非常简单，用一个注解标记需要记录的方法即可。例如发布、下架、删除、修改关键状态的操作，都往日志表插一条记录：操作人ID、操作类型、目标ID、IP、时间、备注。这部分代码量不大，但会给论文里的“系统安全性设计”提供真实可讲的素材。届时老师追问“如果学生投诉一个岗位怎么办”，你就不只是说“可以删掉”，而是能说“先强制下架，再通过日志表留痕，最后受理举报记录”，整个系统的高度立刻不一样。

6.3 答辩演示的常见顺序：先闭环、再细节、后扩展

演示时不要从上到下把所有页面点一遍，那只是“看功能”。更好的一种顺序是先讲一个完整故事：企业注册并通过审核，发布兼职，学生搜索到这条兼职并报名，企业端把状态改成录取，学生端看到已录取，最后标记完成并写一条评价。

整个过程一旦走通，你才去补充权限边界：比如尝试用学生账号调用后台接口，被拦下来；尝试用普通企业在未审核状态发布岗位，提示等待审核。这两次“被拒绝”比几十次“被允许”更能体现系统的价值，也是答辩老师最想看到的正常情况处理。

最后你可以拿出一两句话讲未来扩展方向——比如增加信用评分和黑名单机制，把已经做好的评价表和举报记录承接起来。但千万不要被问“为什么没有做”时慌，只要核心闭环成立，扩展点就是加分项，前提是你要把它说得很具体，而不是泛泛地说“之后可以加”。

我自己在录制这套系统演示录像的时候，最常用也最想分享的一个小操作是：提前准备两个浏览器窗口，一个学生端，一个企业端，全程不开开发者工具去硬解释接口。鼠标点下报名的一瞬间，切到企业端刷新列表，状态从“待处理”变成“已报名”；企业点完录取，再切回学生端刷新，页面按钮自动从“报名中”变换成“已录用/待完成”。这个状态翻转的可视化效果，比任何功能清单都更能说明项目在业务流程上的完成度。

如果你正在拿一套现成源码做二次开发，别急着想把页面标题改得花里胡哨——先沿着报名记录这张表把状态链路走通，把“谁在什么条件下能不能修改状态”这个问题回答干净。能把这件小事做好，系统的骨架就已经立住了；至于页面、动画、富文本，都只是锦上添花的后续动作。