简介这份资源是面向计算机专业应届生与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 一套代码能同时出小程序和 H5Spring 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 岗位表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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 报名表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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 商家资质表管理员审核商家用 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 审核记录表留痕论文里也好写 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有几个参数值得单独说。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)) { // 把用户信息塞进 requestController 直接取 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默认 0publish_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只需要jobIdstudentId从 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 ResultT { private int code; // 200成功4xx客户端错误5xx服务端错误 private String msg; private T data; public static T ResultT ok(T data) { ResultT r new Result(); r.code 200; r.msg success; r.data data; return r; } public static T ResultT fail(String msg) { ResultT 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 跑一遍把正常流程和异常流程都走一遍确认返回符合预期再往下。这个习惯让我在答辩前一周基本不用改代码省下来的时间全用来打磨论文和演示。希望帮到你。本文还有配套的精品资源点击获取
简介这份资源是面向计算机专业应届生与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 一套代码能同时出小程序和 H5Spring 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 岗位表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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 报名表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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 商家资质表管理员审核商家用 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 审核记录表留痕论文里也好写 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有几个参数值得单独说。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)) { // 把用户信息塞进 requestController 直接取 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默认 0publish_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只需要jobIdstudentId从 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 ResultT { private int code; // 200成功4xx客户端错误5xx服务端错误 private String msg; private T data; public static T ResultT ok(T data) { ResultT r new Result(); r.code 200; r.msg success; r.data data; return r; } public static T ResultT fail(String msg) { ResultT 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 跑一遍把正常流程和异常流程都走一遍确认返回符合预期再往下。这个习惯让我在答辩前一周基本不用改代码省下来的时间全用来打磨论文和演示。希望帮到你。本文还有配套的精品资源点击获取
