简介：这份资源是面向计算机专业应届生与Java进阶学习者的毕业设计完整方案，聚焦大学生校园兼职信息管理场景，采用微信小程序（uniapp）作为用户端、SpringBoot构建后端、Vue搭建管理端，数据库选用MySQL，可帮助读者快速完成一套可运行、可答辩的校园兼职管理系统。压缩包共1790个文件，约62.69MB，涵盖238个vue页面组件、121个java后端类、214个js逻辑脚本、96个wxss与94个wxml小程序页面，以及json配置、png/svg图标、sql建表脚本和论文文档，前后端与数据库资源齐备。系统按管理员与用户划分权限，管理员可管理字典、论坛、公告、兼职、收藏、留言、申请、商家与用户等模块，业务链路完整。目前已有106人学习下载，适合需要完整源码、数据库脚本与论文参考的毕业设计选题人群，也便于二次开发与课程实践。
1. 校园兼职小程序这套技术栈，到底值不值得动手做
每年到毕业设计选题那几周，后台总有人问我同一个问题：想做一个校园兼职方向的小程序，用 uniapp 写前端、Spring Boot 写后端、Vue 写管理端，这套组合到底能不能跑通，会不会做到一半发现坑太多直接翻车。我的回答一直是：这套技术栈是目前校园兼职管理系统里最稳、最容易复现、也最容易讲清楚的一条路线，前提是你得知道它每个环节在干什么，而不是把三份代码拼在一起就交差。
校园兼职管理系统要解决的核心问题其实很朴素：学生想找靠谱的兼职，商家想发布岗位并管理报名，学校想审核信息、防止虚假招聘。这三方诉求落到系统里，就是一套典型的多角色权限系统，加上岗位发布、报名审核、状态流转这几条主线业务。uniapp 负责把学生端和商家端塞进微信小程序，Spring Boot 提供接口和权限控制，Vue 管理端给学校管理员做审核和统计。选这套组合不是因为时髦，而是因为 uniapp 一套代码能同时出小程序和 H5，Spring Boot 生态成熟、资料多、排错容易，Vue 管理端上手快、组件库全。对毕业设计来说，能在有限时间里把业务跑通、把论文写实，比追新技术重要得多。
这篇文章面向的是准备动手做这套系统的人：你可能刚定题，也可能代码写了一半卡在某个接口上。我会按「先讲清楚每个模块为什么这么设计，再给能直接抄的代码和参数，最后把踩过的坑摊开讲」的顺序往下走，尽量让你少走弯路。
2. 先把三角色权限模型立住：uniapp、Spring Boot、Vue 各管什么
很多人一上来就急着建表、写接口，结果做到一半发现学生能改商家发布的岗位，或者管理员审核完状态对不上。根子在于权限模型没先立住。校园兼职系统的权限不像普通博客那么随意，它有三个角色：学生、商家、管理员，每个角色能看到的数据范围、能执行的操作都不一样。这一章先把角色边界和数据流讲清楚，再落到具体的表结构和接口分层上。
2.1 三个角色各自的数据边界与操作权限
学生端的核心动作是浏览岗位、投递报名、查看报名状态、维护个人简历。学生只能看到已审核通过的岗位，只能操作自己的报名记录，不能看到其他学生的报名信息。商家端的核心动作是发布岗位、查看报名列表、接受或拒绝报名、下架岗位。商家只能操作自己发布的岗位，看不到别家商家的数据。管理员端的核心动作是审核岗位、审核商家资质、管理用户、查看统计。管理员拥有全量数据的读写权限，但一般不直接参与业务流转，只做审核和兜底。
把这三条边界写成一句话：学生看岗位投报名，商家发岗位管报名，管理员审岗位管全局。任何一条接口在写之前，先问自己「这个接口允许哪个角色调、能操作哪些数据」，想不清楚就先别写。
落到数据库上，用户表用一张user表存基础信息，用role字段区分角色，值分别是student、merchant、admin。岗位表job里必须有merchant_id字段，报名表application里必须有student_id和job_id。这样任何一次查询都能通过where merchant_id = 当前登录用户或where student_id = 当前登录用户把数据范围卡死。
2.2 数据库表结构：五张核心表怎么设计
校园兼职系统的表不用多，五张核心表就能撑起全部业务：用户表、岗位表、报名表、商家资质表、审核记录表。下面给出建表 SQL，字段类型和索引都按实际会查的场景来定。
-- 用户表：三个角色共用，用 role 区分 CREATE TABLE `user` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `openid` VARCHAR(64) DEFAULT NULL COMMENT '微信openid，学生/商家登录用', `username` VARCHAR(32) NOT NULL COMMENT '登录名', `password` VARCHAR(128) NOT NULL COMMENT 'BCrypt加密后的密码', `role` VARCHAR(16) NOT NULL DEFAULT 'student' COMMENT 'student/merchant/admin', `real_name` VARCHAR(32) DEFAULT NULL, `phone` VARCHAR(20) DEFAULT NULL, `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1正常 0禁用', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY `uk_username` (`username`), KEY `idx_openid` (`openid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 岗位表：merchant_id 是数据隔离的关键 CREATE TABLE `job` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `merchant_id` BIGINT NOT NULL COMMENT '发布商家', `title` VARCHAR(64) NOT NULL, `content` TEXT NOT NULL, `salary` VARCHAR(32) DEFAULT NULL COMMENT '薪资描述，如 20元/小时', `work_time` VARCHAR(64) DEFAULT NULL, `location` VARCHAR(128) DEFAULT NULL, `headcount` INT NOT NULL DEFAULT 1 COMMENT '招聘人数', `audit_status` TINYINT NOT NULL DEFAULT 0 COMMENT '0待审核 1通过 2驳回', `publish_status` TINYINT NOT NULL DEFAULT 1 COMMENT '1上架 0下架', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY `idx_merchant` (`merchant_id`), KEY `idx_audit` (`audit_status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 报名表：student_id + job_id 唯一，防止重复报名 CREATE TABLE `application` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `job_id` BIGINT NOT NULL, `student_id` BIGINT NOT NULL, `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0待处理 1已接受 2已拒绝', `apply_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY `uk_job_student` (`job_id`, `student_id`), KEY `idx_student` (`student_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 商家资质表：管理员审核商家用 CREATE TABLE `merchant_profile` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `user_id` BIGINT NOT NULL, `company_name` VARCHAR(64) NOT NULL, `license_no` VARCHAR(64) DEFAULT NULL, `audit_status` TINYINT NOT NULL DEFAULT 0 COMMENT '0待审核 1通过 2驳回', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY `uk_user` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 审核记录表：留痕，论文里也好写 CREATE TABLE `audit_log` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `target_type` VARCHAR(16) NOT NULL COMMENT 'job/merchant', `target_id` BIGINT NOT NULL, `admin_id` BIGINT NOT NULL, `result` TINYINT NOT NULL COMMENT '1通过 2驳回', `remark` VARCHAR(255) DEFAULT NULL, `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY `idx_target` (`target_type`, `target_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这里有几个参数值得单独说。application表的uk_job_student唯一索引是防止学生重复报名的第一道防线，比在代码里查一遍再插入更可靠，因为并发下代码查重会漏。job表的audit_status和publish_status拆成两个字段，是因为审核通过不等于一直上架，商家可以主动下架，管理员也可以强制下架，两个状态分开才不会互相覆盖。user表的password用 BCrypt 加密后长度会到 60 位左右，所以给 128 位留足空间，别用 MD5，论文答辩时被问到安全性会很难看。
2.3 后端接口分层：Controller 只做参数校验，权限交给拦截器
Spring Boot 这边最常见的翻车方式是：每个 Controller 方法里手动写一遍「当前用户是不是商家」「这个岗位是不是他的」，代码重复不说，漏写一个就是越权漏洞。正确做法是把角色校验和登录校验抽到拦截器里，Controller 只负责参数校验和业务调用。
// JwtInterceptor：统一做登录校验和角色校验 @Component public class JwtInterceptor implements HandlerInterceptor { @Autowired private JwtUtil jwtUtil; @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录、注册等公开接口 if (!(handler instanceof HandlerMethod)) { return true; } HandlerMethod hm = (HandlerMethod) handler; // 方法上有 @RequireRole 才校验角色 RequireRole requireRole = hm.getMethodAnnotation(RequireRole.class); if (requireRole == null) { return true; } String token = request.getHeader("Authorization"); if (token == null || !jwtUtil.validate(token)) { response.setStatus(401); return false; } String role = jwtUtil.getRole(token); // 角色不在允许列表里直接拒绝 for (String allow : requireRole.value()) { if (allow.equals(role)) { // 把用户信息塞进 request，Controller 直接取 request.setAttribute("userId", jwtUtil.getUserId(token)); request.setAttribute("role", role); return true; } } response.setStatus(403); return false; } }这段代码的关键在于@RequireRole注解和拦截器的配合。Controller 方法上写@RequireRole({"merchant"})，拦截器就会自动校验 token 里的角色，不在允许列表里直接返回 403。request.setAttribute("userId", ...)把当前用户 ID 传下去，Controller 里用request.getAttribute("userId")取，避免每个方法都解析一遍 token。参数说明：jwtUtil.validate要校验签名和过期时间，getRole从 payload 里取角色字段，这两个方法别偷懒写成固定返回，否则拦截器形同虚设。
2.4 uniapp 端请求封装：token 怎么带、401 怎么处理
uniapp 这边最容易出的问题是 token 过期后页面白屏或者一直转圈。正确做法是封装一个统一的请求方法，在请求头里带 token，遇到 401 自动跳登录页。
// utils/request.js const BASE_URL = 'https://your-domain.com/api'; function request(options) { return new Promise((resolve, reject) => { uni.request({ url: BASE_URL + options.url, method: options.method || 'GET', data: options.data || {}, header: { 'Content-Type': 'application/json', // 从本地缓存取 token，没有就是空串 'Authorization': uni.getStorageSync('token') || '' }, success: (res) => { if (res.statusCode === 401) { // token 失效，清缓存跳登录 uni.removeStorageSync('token'); uni.reLaunch({ url: '/pages/login/login' }); reject(new Error('未登录')); return; } if (res.statusCode === 403) { uni.showToast({ title: '无权限操作', icon: 'none' }); reject(new Error('无权限')); return; } if (res.data.code !== 200) { uni.showToast({ title: res.data.msg || '请求失败', icon: 'none' }); reject(new Error(res.data.msg)); return; } resolve(res.data.data); }, fail: (err) => { uni.showToast({ title: '网络异常', icon: 'none' }); reject(err); } }); }); } export default request;逻辑说明：Authorization头直接放 token 原文，后端拦截器按同样格式取。401 和 403 分开处理，401 是没登录或 token 过期，跳登录页；403 是登录了但角色不对，只提示不跳转，因为跳了也没用。res.data.code !== 200是业务层错误，比如「岗位已下架」，这种只弹提示不跳转。参数上，BASE_URL要换成你自己的后端地址，小程序正式环境必须用 https，开发阶段可以在微信开发者工具里勾选「不校验合法域名」。
3. 岗位发布到报名审核：一条业务主线的完整实现
权限模型立住之后，接下来把最核心的一条业务主线跑通：商家发布岗位、管理员审核、学生报名、商家处理报名。这条线串起来，系统就活了。这一章按业务顺序给代码，每一步都说明为什么这么写、参数怎么定。
3.1 商家发布岗位接口：参数校验和默认状态
商家发布岗位时，岗位不能直接对学生可见，必须先经过管理员审核。所以插入时audit_status默认 0，publish_status默认 1，等审核通过后学生才能查到。
@RestController @RequestMapping("/api/job") public class JobController { @Autowired private JobService jobService; // 只有商家能发布岗位 @PostMapping("/publish") @RequireRole({"merchant"}) public Result publish(@RequestBody @Valid JobPublishDTO dto, HttpServletRequest request) { Long merchantId = (Long) request.getAttribute("userId"); // 校验商家资质是否已通过 if (!jobService.merchantAudited(merchantId)) { return Result.fail("商家资质未通过审核，暂不能发布岗位"); } jobService.publish(merchantId, dto); return Result.ok(); } }JobPublishDTO里对title、content、headcount加@NotBlank、@Min(1)这类校验注解，参数不合法直接返回 400，不用进业务层。merchantAudited这一步很多人会漏，结果没资质的商家也能发岗位，管理员审核压力全堆在岗位审核上。正确顺序是先审商家资质，再让商家发岗位，两道关卡各管各的。
3.2 管理员审核岗位：状态流转和审核留痕
管理员审核岗位时，除了改job表的audit_status，还要往audit_log表插一条记录。留痕这件事在毕业设计里很加分，论文里可以写「系统实现了完整的审核追溯机制」。
@PostMapping("/audit") @RequireRole({"admin"}) @Transactional(rollbackFor = Exception.class) public Result audit(@RequestBody @Valid JobAuditDTO dto, HttpServletRequest request) { Long adminId = (Long) request.getAttribute("userId"); // 1. 更新岗位审核状态 Job job = jobService.getById(dto.getJobId()); if (job == null) { return Result.fail("岗位不存在"); } if (job.getAuditStatus() != 0) { return Result.fail("该岗位已审核，请勿重复操作"); } job.setAuditStatus(dto.getResult()); // 1通过 2驳回 jobService.updateById(job); // 2. 写审核日志 AuditLog log = new AuditLog(); log.setTargetType("job"); log.setTargetId(dto.getJobId()); log.setAdminId(adminId); log.setResult(dto.getResult()); log.setRemark(dto.getRemark()); auditLogService.save(log); return Result.ok(); }@Transactional保证更新岗位和写日志要么都成功要么都回滚，不会出现岗位改了但日志没写的情况。job.getAuditStatus() != 0这个判断是防重复审核，管理员手快连点两次不会把状态改乱。参数上，dto.getResult()只允许 1 或 2，在 DTO 里用@Range(min = 1, max = 2)卡住。
3.3 学生报名：唯一索引兜底，别在代码里查重
学生报名接口看起来简单，但并发下最容易出重复报名。正确做法是直接插入，靠数据库唯一索引兜底，捕获唯一键冲突异常后返回友好提示。
@PostMapping("/apply") @RequireRole({"student"}) public Result apply(@RequestBody @Valid ApplyDTO dto, HttpServletRequest request) { Long studentId = (Long) request.getAttribute("userId"); Job job = jobService.getById(dto.getJobId()); // 岗位必须存在、已审核通过、已上架 if (job == null || job.getAuditStatus() != 1 || job.getPublishStatus() != 1) { return Result.fail("岗位不存在或已下架"); } try { Application app = new Application(); app.setJobId(dto.getJobId()); app.setStudentId(studentId); app.setStatus(0); applicationService.save(app); } catch (DuplicateKeyException e) { // 唯一索引 uk_job_student 触发，说明已报过名 return Result.fail("你已报名该岗位，请勿重复提交"); } return Result.ok(); }这里的关键是catch (DuplicateKeyException e)。很多人在插入前先select查一遍有没有报名记录，查完再插，两步之间如果有另一个请求插进来，照样重复。唯一索引是数据库层面的保证，比代码查重可靠得多。参数上，ApplyDTO只需要jobId，studentId从 token 里取，绝不能让学生端传studentId，否则可以替别人报名。
3.4 商家处理报名：状态更新要带条件，防止越权
商家接受或拒绝报名时，必须校验这条报名记录对应的岗位是不是自己的，否则商家 A 可以处理商家 B 的报名。
@PostMapping("/handle") @RequireRole({"merchant"}) public Result handle(@RequestBody @Valid HandleDTO dto, HttpServletRequest request) { Long merchantId = (Long) request.getAttribute("userId"); // 用 job_id 关联查出报名记录，同时校验岗位归属 Application app = applicationService.getById(dto.getApplicationId()); if (app == null) { return Result.fail("报名记录不存在"); } Job job = jobService.getById(app.getJobId()); if (job == null || !job.getMerchantId().equals(merchantId)) { return Result.fail("无权处理该报名"); } if (app.getStatus() != 0) { return Result.fail("该报名已处理"); } app.setStatus(dto.getStatus()); // 1接受 2拒绝 applicationService.updateById(app); return Result.ok(); }job.getMerchantId().equals(merchantId)这一句是防越权的核心，少了它商家就能处理别人的报名。app.getStatus() != 0防重复处理，和审核岗位一个道理。参数上，dto.getStatus()只允许 1 或 2，用@Range卡住。
4. 避坑与排查：这套系统最容易翻车的五个地方
前面把主线跑通了，但实际做的时候，真正让人卡住的往往不是业务逻辑，而是一些环境、配置、跨域、登录态的问题。这一章把我和身边人踩过的坑按「现象 → 原因 → 解决」列出来，你遇到类似情况可以直接对号入座。
4.1 小程序请求后端一直失败，开发者工具却正常
现象：微信开发者工具里接口能通，真机预览时所有请求都失败，提示「request:fail」。
原因：微信小程序正式环境要求所有请求域名必须在后台配置合法域名，且必须是 https。开发者工具默认勾选了「不校验合法域名」，所以本地 http 能通，真机不勾选就全挂。
解决：开发阶段在开发者工具「详情 → 本地设置」里勾选「不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书」，真机调试时在手机微信里打开调试模式。上线前必须把后端域名配到小程序后台的 request 合法域名里，且证书要有效。
4.2 跨域报错，Vue 管理端调接口被浏览器拦
现象：Vue 管理端本地npm run serve起来后，调后端接口浏览器控制台报 CORS 错误，请求发不出去。
原因：Vue 开发服务器和后端不在同一个端口，浏览器同源策略拦截。小程序端不受同源策略限制，所以只有管理端会遇到。
解决：两种方式，推荐第一种。第一种是在 Vue 的vue.config.js里配代理，把/api转发到后端：
// vue.config.js module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, pathRewrite: { '^/api': '/api' } } } } };第二种是后端加 CORS 配置，但生产环境不建议放开所有来源。参数上，changeOrigin: true必须加，否则后端收到的 Host 还是前端地址，某些框架会拒绝。
4.3 token 存了但接口还是 401，问题出在请求头格式
现象：登录成功后 token 存进了uni.setStorageSync，但调需要登录的接口还是返回 401。
原因：请求头里 token 的格式和后端解析的格式不一致。常见的是前端带了Bearer前缀，后端按原文解析，或者反过来。
解决：前后端约定好格式，要么都带Bearer，要么都不带。我一般不带前缀，直接放 token 原文，后端拦截器里request.getHeader("Authorization")取出来直接用。如果用了 Spring Security 的默认过滤器，它期望Bearer前缀，那就前端统一加。关键是两边一致，别一边加一边不加。
4.4 岗位列表查出来是空的，审核状态和上架状态搞混
现象：管理员明明审核通过了岗位，学生端列表还是空的。
原因：学生端查询条件写成了audit_status = 1，但漏了publish_status = 1，或者商家发布时publish_status默认值设成了 0。
解决：学生端查询必须同时满足audit_status = 1 AND publish_status = 1。建表时publish_status默认值设 1，商家发布后默认上架，审核通过即可见。如果业务要求审核通过后才上架，那就在审核通过时把publish_status也置 1，但这样商家就没法主动下架了，所以还是默认上架、商家可下架更合理。
4.5 报名人数统计对不上，count 查了已拒绝的记录
现象：商家看到的报名人数比实际多，把已拒绝的也算进去了。
原因：统计报名人数时只按job_id查了application表，没过滤status。
解决：统计有效报名人数时加status != 2，或者只统计status = 1的已接受人数。具体看业务口径：如果「报名人数」指所有提交过报名的人，那不过滤；如果指「待处理 + 已接受」，那要排除已拒绝。这个口径在论文里要写清楚，别自己都说不明白。
5. 让这套系统在答辩时站得住：三个进阶技巧
代码跑通只是及格线，真正让这套校园兼职系统在答辩时站得住的，是你能不能讲清楚「为什么这么设计」和「边界在哪里」。这一章给三个具体技巧，都是我自己做类似系统时验证过、也确实能在答辩现场加分的做法。
5.1 用状态机把岗位和报名的流转讲清楚
岗位和报名的状态流转是答辩老师最爱问的点。与其临场组织语言，不如在代码里就把状态流转显式写出来，答辩时直接打开代码讲。
// JobStatus 枚举：把状态和允许的流转写死 public enum JobStatus { PENDING(0, "待审核"), APPROVED(1, "已通过"), REJECTED(2, "已驳回"); private final int code; private final String desc; JobStatus(int code, String desc) { this.code = code; this.desc = desc; } // 判断从当前状态能否流转到目标状态 public boolean canTransferTo(JobStatus target) { if (this == PENDING) { return target == APPROVED || target == REJECTED; } // 已通过或已驳回的不能再改 return false; } public int getCode() { return code; } public String getDesc() { return desc; } }有了这个枚举，审核接口里就能写if (!currentStatus.canTransferTo(targetStatus)) return Result.fail("状态不允许流转")，比一堆 if-else 清楚得多。答辩时老师问「已驳回的岗位能不能再审核通过」，你直接指这段代码，说「不能，状态机限制了」，比口头解释有说服力。
5.2 接口返回统一封装，错误码分层次
很多人的接口返回格式五花八门，有的返回{code, msg, data}，有的直接返回对象，前端处理起来很痛苦。统一封装不只是好看，答辩时也能体现工程规范。
public class Result<T> { private int code; // 200成功，4xx客户端错误，5xx服务端错误 private String msg; private T data; public static <T> Result<T> ok(T data) { Result<T> r = new Result<>(); r.code = 200; r.msg = "success"; r.data = data; return r; } public static <T> Result<T> fail(String msg) { Result<T> r = new Result<>(); r.code = 400; r.msg = msg; return r; } }错误码分层次的意思是：200 成功，400 参数或业务错误，401 未登录，403 无权限，500 服务端异常。前端按 code 做不同处理，401 跳登录，403 提示无权限，400 弹业务提示。这样前端不用去猜msg里写了什么，逻辑清晰。
5.3 论文里怎么把「技术选型」写出说服力
答辩时被问「为什么用 uniapp 不用原生小程序」「为什么用 Spring Boot 不用别的」，别只说「因为流行」。我一般会从三个角度答：第一，开发效率，uniapp 一套代码同时出小程序和 H5，校园兼职系统经常需要 H5 分享到群里，原生小程序做不到；第二，生态成熟度，Spring Boot 的权限、事务、ORM 方案都有现成的，毕业设计时间有限，不该花在造轮子上；第三，可维护性，Vue 管理端组件库丰富，管理员界面能快速搭出来，后期加统计图表也方便。
这三个角度落到论文里，就是「技术选型依据」那一节的内容。别写成产品介绍，写成「我的场景需要什么，这个技术刚好满足什么」，逻辑就立住了。
最后说个我自己的习惯：每次做完一个模块，先不急着做下一个，而是把当前模块的接口用 Postman 或 Apifox 跑一遍，把正常流程和异常流程都走一遍，确认返回符合预期再往下。这个习惯让我在答辩前一周基本不用改代码，省下来的时间全用来打磨论文和演示。希望帮到你。
本文还有配套的精品资源，点击获取
