坦白说第一眼看到“蜗牛兼职网”这个名字我就觉得这不是一个随便做着玩的课设。兼职类平台最大的难点从来不是“发布职位”和“投递简历”这两个动作而是怎么把不同角色、不同状态、不同权限之间那些藕断丝连的逻辑理清楚。尤其当你选了SpringBoot2 Vue3 MyBatis-Plus MySQL8.0这套组合你会发现框架本身能帮你解决七成的问题剩下三成全藏在表设计和状态流转里。这个项目从源码到文档都齐备适合拿来作为毕业设计、课程设计也适合想完整走一遍“前后端分离 管理系统”链路的人参考。我按自己实际接手类似项目时的思路把整件事从需求拆解到部署上线拆开讲一遍重点讲那些你看完官方文档也不一定想得到、但联调时一定会踩的细节。1. 项目定位与需求拆解先分清“谁在用什么”再谈技术选型兼职平台这种项目需求边界特别容易被一句话带过去。很多人一听“兼职网”第一反应就是学生发布简历、企业发布岗位然后双方对接就完事了。真画起原型来你会发现至少有三类使用者而每一类人看到的内容和能做的操作完全不同。1.1 从需求源头拆出的四端模型我把蜗牛兼职网的参与者拆成四端游客、求职学生、企业管理员、平台管理员。游客能浏览岗位列表和平台介绍但不能投递学生登录后可完善简历、投递岗位、查看进度、结算和评价企业端负责发布岗位、审核投递、标记雇佣状态、做结算确认平台管理员则是终审角色负责企业资质审核、岗位违规下线、用户封禁和内容管理。与之对应的功能模块就非常清晰了注册登录与实名认证、岗位发布与管理、投递流程管理、简历管理、结算与评价、消息通知、后台数据看板、系统管理。这套模块列表粗看很常规但它决定了数据库要建多少张表、每张表的字段要到什么粒度甚至决定了后面接口的嵌套层级。把模块先拆到这个程度再去看Maven依赖和Vue页面你才不会被源码牵着走。1.2 数据模型是整个项目的主干表设计是这个项目里最值得花时间的部分。基于上面的功能拆解蜗牛兼职网至少需要这样几类核心表表分组核心表承担职责用户体系sys_user、student_profile、company_profile统一登录账号与两类身份的信息扩展岗位业务job_post、job_category、job_apply岗位发布、分类检索、投递记录流程管理apply_status_log、settlement_record状态变更留痕、兼职结算流水运营管理audit_record、feedback、notice审核、用户反馈、公告消息系统支撑sys_role、sys_menu、sys_user_roleRBAC权限模型支撑后台管理你仔细观察会发现我没有把“用户”和“学生、企业”直接设计成三类独立的账号表而是让sys_user作为统一账号基础表再用student_profile和company_profile做一对一扩展。这样做的直接好处是无论登录入口是学生端还是企业端底层都能用同一套账号密码体系做认证后续做平台管理员也只需要在这张表里加一个role关联就行不用维护三套session。同样值得留意的是apply_status_log这类日志表。很多初版项目会把投递状态只做成job_apply里的一个字符串字段等到要展示“当前状态”“历史流转时间”的时候才发现数据不够用。加一张状态日志表虽然写代码时多几条insert但后台的审核跟踪、学生端的时间线展示都变成了简单的列表查询属于典型的“前期加表、后期省心”。2. 技术栈选型复盘为什么是这套组合而不是“看着更潮流”的方案SpringBoot2、Vue3、MyBatis-Plus、MySQL8.0这四个词在现在的简历里几乎快变成标配了但每个选型背后都有具体的现实考量不是拼盘式堆砌。理解这层逻辑比单纯跑通源码重要得多。2.1 后端框架SpringBoot2与JDK8的稳定组合在已经有SpringBoot3和JDK17的当下为什么不少真实项目仍然固定在SpringBoot2环境因为大量公司和高校服务器上的JDK还是8。SpringBoot3的最低要求是JDK17SpringBoot2.7.x对JDK8的兼容性已经非常成熟而且javax.*命名空间在Servlet、Validation等场景里积累了一堆现成代码迁移到jakarta.*的成本即便不高也不是“刚把项目跑起来”的人愿意额外承担的。对蜗牛兼职网这种前后端分离项目SpringBoot2主要提供这几块价值内置Tomcat和自动配置能大幅压缩接口开发时的配置代码Spring MVC注解模型清晰RESTful接口定义直观与MyBatis-Plus、MySQL驱动、Redis等第三方库的兼容经验非常丰富遇到问题随手一搜就有答案。有人会问那直接用更老的SpringBoot1.x行不行不是不行是它的自动配置机制和较新的依赖体系已经有摩擦而且安全补丁和社区支持明显不足。2.7.x这个版本段算是“要稳定有稳定要功能有功能”的平衡点。2.2 持久层MyBatis-Plus解决的是“单表CRUD”的重复劳动选MyBatis-Plus而不用原生MyBatis是因为这种业务系统里有大量的单表操作。用户注册插入一条记录、修改简历更新一个字段、查询岗位列表带分页这些事情如果每件都手写SQL整个项目会堆积大量同质化代码。MyBatis-Plus提供的几个核心能力恰好覆盖这些场景BaseMapper提供通用的insert、updateById、deleteById、selectById基本告别简单SQL内置PaginationInnerInterceptor分页插件配合Page对象可以直接拿到total和records逻辑删除功能可以用一个deleted字段统一实现“软删除”避免用户误删后无法找回自动填充机制能统一处理createTime、updateTime这类审计字段。不过要提醒一句MyBatis-Plus对单表操作是神器一旦涉及复杂的多表关联查询它并不比手写SQL快。蜗牛兼职网里岗位列表要显示公司名和分类名称这类场景我建议直接在Mapper里写XML用JOIN把数据查出来再用DTO接收。别迷信框架该手写时别犹豫。2.3 前端Vue3 组合式API更适合中后台复杂度Vue3相对于Vue2最大的变化不是语法而是响应式系统的重构和组合式API带来的逻辑复用方式。兼职平台前端页面数量不少却多属于“表单 列表 状态展示”的中后台风格。Options API写这类页面时data、methods、computed会被切成三段多个页面之间要抽公共逻辑只能靠mixin混用多了非常难排查。组合式API可以按业务功能拆出独立的函数比如把“登录后获取用户信息并写入Pinia”这个动作放在一个useUser函数里任何页面或组件需要用到时直接调用逻辑内聚可读性也更好。配合Pinia做状态管理token、用户信息、未读消息数这些全局状态都能跨页面共享不用做事件总线那套绕弯的事。2.4 数据库MySQL8.0带来的不只是默认utf8mb4MySQL8.0较旧版本最直观的变化是默认字符集变为utf8mb4emoji和特殊字符不再需要额外配置。另一个实用的改进是支持窗口函数和公用表表达式这让“按分类统计岗位数量并带上排名”之类的查询比MySQL5.7时代优雅很多。同时8.0改进了查询优化器很多慢SQL的执行计划更合理。但这个版本也有个坑后面我会专门讲到它默认的认证插件是caching_sha2_password老版本的连接驱动、或者没有配置allowPublicKeyRetrievaltrue的JDBC连接串会在启动时直接报Public Key Retrieval is not allowed。这个错误几乎每个从5.7切到8.0的人都会遇到。技术组件推荐版本理由JDK1.8建议8u201以上与SpringBoot2生态完全兼容SpringBoot2.7.x稳定且资料丰富支持JDK8MyBatis-Plus3.5.x分页插件、逻辑删除、字段自动填充MySQL8.0.x窗口函数、utf8mb4、性能优化Vue33.4.x组合式API完善依赖维护活跃Node16.20Vite构建Vue3项目的最低要求3. 后端核心实现登录态、数据权限和状态机的设计思路跑通一个接口容易把整个系统的权限边界和流程边界划清楚难。蜗牛兼职网的业务中学生、企业、管理员三类角色频繁切换视角后端如果不在接口层做严格的控制很容易被前端操作路径带着走最终出现越权问题。3.1 登录认证一学就会的Token 拦截器方案做这个项目时我接触过不少同学的第一版实现普遍直接用Session存登录态。前后端分离项目用Session不是不行但要考虑跨域携带Cookie、CSRF攻击、移动端复用等问题整体不如Token方案干净。我采用的是“登录成功后签发Token 每次请求携带Token 拦截器解析Token ThreadLocal保存当前用户”这条链路。选Token方案并不意味着必须引入完整的Spring Security对这个体量的项目来说手写一个认证拦截器完全够用而且能让你把每一步都看得清清楚楚。核心逻辑大概是登录接口校验用户名密码。密码在数据库里存的是BCrypt密文Spring Security Crypto包里自带的BCryptPasswordEncoder就能做加密和校验。校验通过后生成一个Token负载里放userId和角色代码。生成算法可以用JWT库也可以用UUID Token存储在Redis里的方式。蜗牛兼职网考虑到多端登出和账号封禁的实时性使用Redis存储Token拦截器每轮查询Redis校验Token是否仍有效。拦截器从请求头取出Token解析出userId查出用户基础信息放入ThreadLocal。业务方法里通过UserContext.getCurrentUser()获取当前身份。public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || token.isEmpty()) { throw new BizException(401, 未登录); } LoginUser loginUser tokenService.parseAndValidate(token); UserContext.set(loginUser); return true; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { UserContext.clear(); } }这个方案里有两点容易被忽略一是afterCompletion里必须手动清除ThreadLocal否则Tomcat线程池复用时下一个请求可能读到上一个请求的用户信息二是静态资源和登录、注册、岗位列表等公开接口要配置在拦截器白名单里否则前端首次加载就会报401。3.2 岗位和投递的状态机用一张字段还是用一张日志表岗位本身有状态草稿、待审核、审核不通过、已发布、已下架。投递记录也有自己的状态已投递、已查看、已面试、已录用、已拒绝、已完成、已取消。两套状态不能混在一个字段里必须分开管理。每个状态的迁移需要明确约束我列一下岗位状态的核心流转企业创建岗位后默认是草稿提交审核后变成待审核平台管理员通过后变成已发布已发布岗位可以被企业主动下架也可以因为被举报被管理员强制下架审核不通过的岗位企业修改后可以重新提交。投递状态相比之下更复杂因为它同时牵扯学生和企业两个角色的操作当前状态可执行操作目标状态操作角色已投递查看简历已查看企业已投递 / 已查看通过初筛待面试企业待面试确认面试通过已录用企业已录用确认到岗进行中学生亦可企业确认进行中发起结算待结算学生/企业已录用拒绝录用已拒绝学生任意非终态取消投递已取消学生状态机的落地方式我强烈建议配合apply_status_log表。每发生一次状态变更除了更新job_apply.status字段还往日志表插一条记录携带操作人、操作时间、变更前后状态和备注。这样前端展示时间线时一次查询就能拿到全部数据后台排查问题时也能还原每一次关键操作比起只更新一个字段遇到纠纷时省的时间不可估量。3.3 数据权限别让普通用户改掉别人的数据数据权限是这个项目里最容易被轻视的一环。很多初版实现只做了登录拦截没有做记录归属校验于是出现了非常典型的问题一个学生调接口把另一个学生的简历手机号改了或者一个企业账号把另一家公司的岗位下架了。实际上解决办法不复杂就是在更新和删除接口里强制做“归属判断”。企业删除岗位时先根据jobId查出岗位的companyId再与当前登录用户所属的companyId比对不一致就抛403。学生撤销投递时同样校验apply记录里的studentId和当前用户id是否相等。这个判断不能只依赖前端隐藏按钮后端接口必须每条都校验我把这类判断统一封在一个DataScopeHelper里凡是涉及写操作都调用它防止漏加。另外还有一个比较隐蔽的细节学生浏览岗位列表时看不到企业完整联系方式只有投递被企业“已查看”或“已录用”后详情接口才返回手机号和微信。这个逻辑通过动态判断投递状态即可实现属于业务型数据权限写进接口文档里避免前端凭空猜测字段什么时候出现。4. 前端Vue3工程实践封装、状态管理和几个容易踩的坑后端逻辑再完整前端接不好体验也白搭。蜗牛兼职网的前端采用Vite Vue3 Pinia Element Plus这套常见组合整体难度不高但有几个点处理得好不好直接决定联调时翻不翻车。4.1 Axios封装统一错误处理与登录过期项目里所有接口都走一个封装好的request模块而不是每个页面单独引入axios发请求。这样做最大的价值在于统一了三件事Token注入、HTTP错误映射、业务码处理。const request axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL, timeout: 10000 }) request.interceptors.request.use(config { const token useAuthStore().token if (token) config.headers.Authorization token return config }) request.interceptors.response.use( response { const res response.data if (res.code 200) return res if (res.code 401) { useAuthStore().logout() router.push(/login) return Promise.reject(new Error(登录已过期)) } ElMessage.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) }, error { ElMessage.error(error.message || 网络异常) return Promise.reject(error) } )这块代码看起来平淡实际上有个高频问题401弹窗重复出现。比如列表页同时发三个请求三个请求都因为Token过期返回401拦截器里连续执行三次logout和三次router.push页面会跳来跳去报错提示弹满屏幕。我的处理方法是引入一个isRefreshing标记和等待队列只让第一个401请求触发重新登录逻辑其余请求排队等待刷新结果。如果刷新Token成功把排队的请求用新Token重新发起如果刷新失败再统一跳登录页。这种并发去重机制在真实项目里用太频繁了但很多资料里不讲属于典型的“代码看得懂、遇事不会用”。4.2 Pinia状态管理只把真正的全局状态放进去Vue3推荐用Pinia管理状态但并非所有数据都该塞进store。如果你把每个页面的搜索条件都放进store页面刷新后还要想办法恢复状态纯属给自己加戏。蜗牛兼职网里我主要放了三类内容token、用户基本信息、未读消息数。这些数据的特点是“几乎每个页面都要用”且“变化会影响所有页面”。至于岗位列表、投递记录这些页面私有数据留在组件内部或临时缓存即可不需要全局共享。Pinia的store里还有一个容易被忽略的问题跨标签页同步。用户在一份浏览器里开两个标签登录同一个账号一边修改了头像另一边可能还是旧缓存。这个问题不需要做完整的跨标签通信简单方案是在请求成功修改个人资料后主动调用一个fetchUserInfo刷新store并在store里比较更新时间。要更极客一点可以用storage事件监听token变化但对我这边项目来说前者已经足够。4.3 路由守卫动态权限与公开页面白名单前端路由不能当作安全边界但它直接影响用户体验。蜗牛兼职网采用静态路由表所有页面写在Routes配置里再通过meta.requiresAuth和meta.roles做访问控制。router.beforeEach((to, from, next) { const authStore useAuthStore() if (to.meta.public) { next() return } if (!authStore.token) { next({ path: /login, query: { redirect: to.fullPath } }) return } if (to.meta.roles !to.meta.roles.includes(authStore.roleCode)) { next({ path: /403 }) return } next() })这里有个细节值得展开用户手动访问一个不属于自己身份的页面时应该跳转到403页面而不是404。很多人习惯把所有不认识的路径直接引向404然后在排查问题时分不清是页面没写还是权限没配。区分开用一句话就能定位问题。5. 联调阶段实测笔记六个我几乎每次都会踩的坑这部分是全文最有操作价值的内容。下面每个问题都来自真实联调场景我给的不是一句话答案而是完整的排查链路方便你遇到类似情况时能顺着思路走。5.1 MySQL8.0连接时报Public Key Retrieval is not allowed现象SpringBoot项目启动后台日志报java.sql.SQLNonTransientConnectionException: Public Key Retrieval is not allowed。排查过程我第一反应是驱动版本不对把mysql-connector-java从5.1.49换成8.0.33问题依旧。后来查连接串发现url里只写了localhost:3306和数据库名。又对照8.0的官方文档才确认是caching_sha2_password认证插件导致的。根治方式JDBC连接串里加上allowPublicKeyRetrievaltrue完事后建议同步加上useSSLfalse和serverTimezoneAsia/Shanghai。前者是开发环境下方便调试后两者是保证SSL验证不打扰本地连接、时区不偏差8小时。这三行参数配上再没见过这类启动报错。提示allowPublicKeyRetrievaltrue在生产环境要谨慎开启因为它允许客户端在建立连接时向服务端申请公钥。如果对传输安全要求高推荐用SSL方式或配置正确的证书而不是用这个开关。5.2 LocalDateTime字段传给前端出现一串数字现象数据库里存的发布时间在接口返回里变成了一大串数字前端拿到后格式化失败。排查过程看JSON数据日期字段被序列化成了时间戳。原因是Jackson默认不认识和LocalDateTime或者项目中没配置JavaTimeModule和禁用WRITE_DATES_AS_TIMESTAMPS。我最初只在application.yml里设了spring.jackson.date-format但那是针对java.util.Date的对java.time包无效。根治方式使用Jackson的自定义配置或者直接给实体类字段上加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)。推荐前者全局配置一次所有LocalDateTime字段都生效。spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8同时新建一个JacksonConfig注册JavaTimeModule并且不把日期序列化为时间戳。两处配置配合前端的dayjs格式化压力小很多。5.3 MyBatis-Plus的updateById更新不了null字段现象学生把简历里的“个人简介”清空保存成功后重新查询发现字段还是旧值。排查过程第一反应是前台传参少了打开Network面板发现请求体里确实有introduction: 。再看后端接口接收对象里的introduction是空字符串而不是null按理说应该能更新。最后才想到MyBatis-Plus默认的字段策略是NOT_NULL也就是只更新非null字段空字符串虽不是null但String字段再配合策略容易出现字段被忽略的混淆情况。根治方式对这个字段使用TableField(updateStrategy FieldStrategy.IGNORED)或者将实体类全局字段策略改成IGNORED。我建议只在特定字段上处理因为全局放开后每次update都会把所有字段拼进SQL既影响性能又容易误更新。提示这里要注意区分两个场景。用户把字段完全清空前端传的是空字符串要让它更新用户根本没传这个字段对象里是null通常应该忽略。所以更精细的方案是DTO里单独标志哪些字段需要强制更新而不是一刀切处理。5.4 分页查询的total总数和实际记录数对不上现象岗位列表用了JOIN查询关联分类表和企业表分页正常但total有时候多出来有时候变小。排查过程MyBatis-Plus分页插件在处理JOIN查询时自动生成的count语句会简单地对主查询包一层select count(*) from (...)这种写法在有些JOIN场景下会把笛卡尔积带进count导致总数虚高。我最初通过手动指定countSql解决后来又发现只要把主SQL和countSql分开优化就可以。根治方式在Mapper的XML里手动写count语句。分页插件允许你在方法上用Select注解或XML方式显式提供count语句别依赖自动生成的。把JOIN条件里的多余字段去掉count语句只统计主表id去重后的数量。select idselectJobPage resultTypecom.demo.dto.JobVO SELECT j.id, j.title, c.name AS companyName, t.name AS categoryName FROM job_post j LEFT JOIN company_profile c ON j.company_id c.user_id LEFT JOIN job_category t ON j.category_id t.id WHERE j.deleted 0 AND j.status PUBLISHED /select select idselectJobPageCount resultTypelong SELECT COUNT(DISTINCT j.id) FROM job_post j WHERE j.deleted 0 AND j.status PUBLISHED /select5.5 修改用户资料后自动填充字段被重置现象更新昵称后createTime竟然变成了当前时间数据库里的历史创建记录被覆盖了。排查过程看实体类里createTime和updateTime都配了MyBatis-Plus的自动填充注解TableField(fill FieldFill.INSERT_UPDATE)。意思是插入和更新都会触发填充逻辑。createTime字段本应该只在插入时填充一次现在却被错误的策略带进去每次update都刷新了。根治方式把createTime改成fill FieldFill.INSERTupdateTime才能用INSERT_UPDATE。同时检查MetaObjectHandler的实现里是否用strictInsertFill和strictUpdateFill分别做了处理不要在更新逻辑里把createTime也塞进来。Component public class MyMetaObjectHandler implements MetaObjectHandler { Override public void insertFill(MetaObject metaObject) { this.strictInsertFill(metaObject, createTime, LocalDateTime.class, LocalDateTime.now()); this.strictInsertFill(metaObject, updateTime, LocalDateTime.class, LocalDateTime.now()); } Override public void updateFill(MetaObject metaObject) { this.strictUpdateFill(metaObject, updateTime, LocalDateTime.class, LocalDateTime.now()); } }5.6 前端页面路由刷新后404现象部署到服务器nginx配置了静态资源和反向代理。用户从岗位列表页点击进入详情页刷新一次nginx报404。排查过程Vue Router用的history模式页面路径是前端路由不是真实文件路径。nginx默认只按静态文件定位刷新详情页时它去磁盘找/site/detail.html找不到就404。第一反应是改hash模式但URL带#号不美观和我预期不符。根治方式配nginx的try_files指令把所有非静态文件请求回退到index.html由前端路由接管。location / { root /opt/snail-web/dist; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }6. 打包部署与验收清单让项目真正可交付项目写完了、本地跑通了离“可交付”还有一步。很多课设和简历项目倒在这一步——代码能run但部署包不完整环境的差异一换就崩。下面是我自己固定使用的一套流程和检查项。6.1 前端构建与后端打包顺序蜗牛兼职网是前后端分离的。前端开发时通过Vite代理访问后端8080端口但部署时有两种常见方式一种是前端和后端完全分开部署前端用nginx提供静态文件后端只暴露API另一种是把前端build出来的dist目录直接复制到后端resources/static下做成单一SpringBoot jar运行。我更推荐第一种因为它让接口层和页面层各自独立。运维上只要改nginx配置就能换前端静态文件后端升级不用动前端。而且如果以后要扩展小程序或App后端API可以直接复用不用再抽一层。前端打包需要注意环境变量。构建前要确保.env.production里的VITE_API_BASE_URL指向可被浏览器访问到的API地址。如果部署在云服务器这里应该填公网域名或服务器IP而不是localhost否则用户在浏览器里请求的地址指向他自己电脑。npm run build mvn clean package -DskipTests后端打包时建议跳过测试避免本地数据库连接不上导致构建失败。打包完成后看jar包大小正常应该包含依赖和配置大概几十MB。6.2 上线前的自测清单这个清单我每次交付前都会过一遍推荐你直接照着抄一份检查项操作动作预期结果登录过期登录后等Token过期再操作页面跳转登录页数据不残留越权访问学生Token调用企业下架接口返回403数据不变更空数据处理岗位列表在无数据时访问页面显示空状态不报错并发投递两账号同时投递同一岗位投递表无重复脏数据文件上传上传超大图片或非法格式后端拒绝前端提示逻辑删除删除岗位后再分页查询列表不出现数据库记录仍存在时间时区服务器切换时区后访问页面时间与本地一致弱口令注册输入纯数字或超短密码校验拦截提示密码强度6.3 文档的价值从“跑起来的项目”到“能参考的系统”标题里特意强调了【含文档】这一点我多说两句。源码再完整如果没有数据库初始化脚本、接口文档和部署说明后来接手的同学基本无从下手。建议交付包至少包含完整的SQL初始化脚本含建库建表、初始管理员账号、基础数据、Postman或Apifox导出的接口测试集、部署环境说明JDK版本、Node版本、MySQL版本、nginx配置示例、以及一个记录疑难问题的FAQ文档。文档不是写给答辩老师看的是写给三个月后的自己看的。我刚做类似系统时也嫌文档累赘等到回读自己代码时才发现当初的设计意图全靠文档才能快速还原。说句实在话有这份文档的价值和没有这份文档的项目在真实工程里完全不是一个等级。整个项目从需求拆解、技术选型、后端状态机、前端封装到最后部署验收每一条线都可以单独深挖。蜗牛兼职网这套源码如果只用来“跑起来看效果”多少有点浪费把它拆开对照着业务点逐层看才是收获最大的方式。真动手改几行代码再跑一遍测试比抱着源码看三遍都有用。
坦白说第一眼看到“蜗牛兼职网”这个名字我就觉得这不是一个随便做着玩的课设。兼职类平台最大的难点从来不是“发布职位”和“投递简历”这两个动作而是怎么把不同角色、不同状态、不同权限之间那些藕断丝连的逻辑理清楚。尤其当你选了SpringBoot2 Vue3 MyBatis-Plus MySQL8.0这套组合你会发现框架本身能帮你解决七成的问题剩下三成全藏在表设计和状态流转里。这个项目从源码到文档都齐备适合拿来作为毕业设计、课程设计也适合想完整走一遍“前后端分离 管理系统”链路的人参考。我按自己实际接手类似项目时的思路把整件事从需求拆解到部署上线拆开讲一遍重点讲那些你看完官方文档也不一定想得到、但联调时一定会踩的细节。1. 项目定位与需求拆解先分清“谁在用什么”再谈技术选型兼职平台这种项目需求边界特别容易被一句话带过去。很多人一听“兼职网”第一反应就是学生发布简历、企业发布岗位然后双方对接就完事了。真画起原型来你会发现至少有三类使用者而每一类人看到的内容和能做的操作完全不同。1.1 从需求源头拆出的四端模型我把蜗牛兼职网的参与者拆成四端游客、求职学生、企业管理员、平台管理员。游客能浏览岗位列表和平台介绍但不能投递学生登录后可完善简历、投递岗位、查看进度、结算和评价企业端负责发布岗位、审核投递、标记雇佣状态、做结算确认平台管理员则是终审角色负责企业资质审核、岗位违规下线、用户封禁和内容管理。与之对应的功能模块就非常清晰了注册登录与实名认证、岗位发布与管理、投递流程管理、简历管理、结算与评价、消息通知、后台数据看板、系统管理。这套模块列表粗看很常规但它决定了数据库要建多少张表、每张表的字段要到什么粒度甚至决定了后面接口的嵌套层级。把模块先拆到这个程度再去看Maven依赖和Vue页面你才不会被源码牵着走。1.2 数据模型是整个项目的主干表设计是这个项目里最值得花时间的部分。基于上面的功能拆解蜗牛兼职网至少需要这样几类核心表表分组核心表承担职责用户体系sys_user、student_profile、company_profile统一登录账号与两类身份的信息扩展岗位业务job_post、job_category、job_apply岗位发布、分类检索、投递记录流程管理apply_status_log、settlement_record状态变更留痕、兼职结算流水运营管理audit_record、feedback、notice审核、用户反馈、公告消息系统支撑sys_role、sys_menu、sys_user_roleRBAC权限模型支撑后台管理你仔细观察会发现我没有把“用户”和“学生、企业”直接设计成三类独立的账号表而是让sys_user作为统一账号基础表再用student_profile和company_profile做一对一扩展。这样做的直接好处是无论登录入口是学生端还是企业端底层都能用同一套账号密码体系做认证后续做平台管理员也只需要在这张表里加一个role关联就行不用维护三套session。同样值得留意的是apply_status_log这类日志表。很多初版项目会把投递状态只做成job_apply里的一个字符串字段等到要展示“当前状态”“历史流转时间”的时候才发现数据不够用。加一张状态日志表虽然写代码时多几条insert但后台的审核跟踪、学生端的时间线展示都变成了简单的列表查询属于典型的“前期加表、后期省心”。2. 技术栈选型复盘为什么是这套组合而不是“看着更潮流”的方案SpringBoot2、Vue3、MyBatis-Plus、MySQL8.0这四个词在现在的简历里几乎快变成标配了但每个选型背后都有具体的现实考量不是拼盘式堆砌。理解这层逻辑比单纯跑通源码重要得多。2.1 后端框架SpringBoot2与JDK8的稳定组合在已经有SpringBoot3和JDK17的当下为什么不少真实项目仍然固定在SpringBoot2环境因为大量公司和高校服务器上的JDK还是8。SpringBoot3的最低要求是JDK17SpringBoot2.7.x对JDK8的兼容性已经非常成熟而且javax.*命名空间在Servlet、Validation等场景里积累了一堆现成代码迁移到jakarta.*的成本即便不高也不是“刚把项目跑起来”的人愿意额外承担的。对蜗牛兼职网这种前后端分离项目SpringBoot2主要提供这几块价值内置Tomcat和自动配置能大幅压缩接口开发时的配置代码Spring MVC注解模型清晰RESTful接口定义直观与MyBatis-Plus、MySQL驱动、Redis等第三方库的兼容经验非常丰富遇到问题随手一搜就有答案。有人会问那直接用更老的SpringBoot1.x行不行不是不行是它的自动配置机制和较新的依赖体系已经有摩擦而且安全补丁和社区支持明显不足。2.7.x这个版本段算是“要稳定有稳定要功能有功能”的平衡点。2.2 持久层MyBatis-Plus解决的是“单表CRUD”的重复劳动选MyBatis-Plus而不用原生MyBatis是因为这种业务系统里有大量的单表操作。用户注册插入一条记录、修改简历更新一个字段、查询岗位列表带分页这些事情如果每件都手写SQL整个项目会堆积大量同质化代码。MyBatis-Plus提供的几个核心能力恰好覆盖这些场景BaseMapper提供通用的insert、updateById、deleteById、selectById基本告别简单SQL内置PaginationInnerInterceptor分页插件配合Page对象可以直接拿到total和records逻辑删除功能可以用一个deleted字段统一实现“软删除”避免用户误删后无法找回自动填充机制能统一处理createTime、updateTime这类审计字段。不过要提醒一句MyBatis-Plus对单表操作是神器一旦涉及复杂的多表关联查询它并不比手写SQL快。蜗牛兼职网里岗位列表要显示公司名和分类名称这类场景我建议直接在Mapper里写XML用JOIN把数据查出来再用DTO接收。别迷信框架该手写时别犹豫。2.3 前端Vue3 组合式API更适合中后台复杂度Vue3相对于Vue2最大的变化不是语法而是响应式系统的重构和组合式API带来的逻辑复用方式。兼职平台前端页面数量不少却多属于“表单 列表 状态展示”的中后台风格。Options API写这类页面时data、methods、computed会被切成三段多个页面之间要抽公共逻辑只能靠mixin混用多了非常难排查。组合式API可以按业务功能拆出独立的函数比如把“登录后获取用户信息并写入Pinia”这个动作放在一个useUser函数里任何页面或组件需要用到时直接调用逻辑内聚可读性也更好。配合Pinia做状态管理token、用户信息、未读消息数这些全局状态都能跨页面共享不用做事件总线那套绕弯的事。2.4 数据库MySQL8.0带来的不只是默认utf8mb4MySQL8.0较旧版本最直观的变化是默认字符集变为utf8mb4emoji和特殊字符不再需要额外配置。另一个实用的改进是支持窗口函数和公用表表达式这让“按分类统计岗位数量并带上排名”之类的查询比MySQL5.7时代优雅很多。同时8.0改进了查询优化器很多慢SQL的执行计划更合理。但这个版本也有个坑后面我会专门讲到它默认的认证插件是caching_sha2_password老版本的连接驱动、或者没有配置allowPublicKeyRetrievaltrue的JDBC连接串会在启动时直接报Public Key Retrieval is not allowed。这个错误几乎每个从5.7切到8.0的人都会遇到。技术组件推荐版本理由JDK1.8建议8u201以上与SpringBoot2生态完全兼容SpringBoot2.7.x稳定且资料丰富支持JDK8MyBatis-Plus3.5.x分页插件、逻辑删除、字段自动填充MySQL8.0.x窗口函数、utf8mb4、性能优化Vue33.4.x组合式API完善依赖维护活跃Node16.20Vite构建Vue3项目的最低要求3. 后端核心实现登录态、数据权限和状态机的设计思路跑通一个接口容易把整个系统的权限边界和流程边界划清楚难。蜗牛兼职网的业务中学生、企业、管理员三类角色频繁切换视角后端如果不在接口层做严格的控制很容易被前端操作路径带着走最终出现越权问题。3.1 登录认证一学就会的Token 拦截器方案做这个项目时我接触过不少同学的第一版实现普遍直接用Session存登录态。前后端分离项目用Session不是不行但要考虑跨域携带Cookie、CSRF攻击、移动端复用等问题整体不如Token方案干净。我采用的是“登录成功后签发Token 每次请求携带Token 拦截器解析Token ThreadLocal保存当前用户”这条链路。选Token方案并不意味着必须引入完整的Spring Security对这个体量的项目来说手写一个认证拦截器完全够用而且能让你把每一步都看得清清楚楚。核心逻辑大概是登录接口校验用户名密码。密码在数据库里存的是BCrypt密文Spring Security Crypto包里自带的BCryptPasswordEncoder就能做加密和校验。校验通过后生成一个Token负载里放userId和角色代码。生成算法可以用JWT库也可以用UUID Token存储在Redis里的方式。蜗牛兼职网考虑到多端登出和账号封禁的实时性使用Redis存储Token拦截器每轮查询Redis校验Token是否仍有效。拦截器从请求头取出Token解析出userId查出用户基础信息放入ThreadLocal。业务方法里通过UserContext.getCurrentUser()获取当前身份。public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || token.isEmpty()) { throw new BizException(401, 未登录); } LoginUser loginUser tokenService.parseAndValidate(token); UserContext.set(loginUser); return true; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { UserContext.clear(); } }这个方案里有两点容易被忽略一是afterCompletion里必须手动清除ThreadLocal否则Tomcat线程池复用时下一个请求可能读到上一个请求的用户信息二是静态资源和登录、注册、岗位列表等公开接口要配置在拦截器白名单里否则前端首次加载就会报401。3.2 岗位和投递的状态机用一张字段还是用一张日志表岗位本身有状态草稿、待审核、审核不通过、已发布、已下架。投递记录也有自己的状态已投递、已查看、已面试、已录用、已拒绝、已完成、已取消。两套状态不能混在一个字段里必须分开管理。每个状态的迁移需要明确约束我列一下岗位状态的核心流转企业创建岗位后默认是草稿提交审核后变成待审核平台管理员通过后变成已发布已发布岗位可以被企业主动下架也可以因为被举报被管理员强制下架审核不通过的岗位企业修改后可以重新提交。投递状态相比之下更复杂因为它同时牵扯学生和企业两个角色的操作当前状态可执行操作目标状态操作角色已投递查看简历已查看企业已投递 / 已查看通过初筛待面试企业待面试确认面试通过已录用企业已录用确认到岗进行中学生亦可企业确认进行中发起结算待结算学生/企业已录用拒绝录用已拒绝学生任意非终态取消投递已取消学生状态机的落地方式我强烈建议配合apply_status_log表。每发生一次状态变更除了更新job_apply.status字段还往日志表插一条记录携带操作人、操作时间、变更前后状态和备注。这样前端展示时间线时一次查询就能拿到全部数据后台排查问题时也能还原每一次关键操作比起只更新一个字段遇到纠纷时省的时间不可估量。3.3 数据权限别让普通用户改掉别人的数据数据权限是这个项目里最容易被轻视的一环。很多初版实现只做了登录拦截没有做记录归属校验于是出现了非常典型的问题一个学生调接口把另一个学生的简历手机号改了或者一个企业账号把另一家公司的岗位下架了。实际上解决办法不复杂就是在更新和删除接口里强制做“归属判断”。企业删除岗位时先根据jobId查出岗位的companyId再与当前登录用户所属的companyId比对不一致就抛403。学生撤销投递时同样校验apply记录里的studentId和当前用户id是否相等。这个判断不能只依赖前端隐藏按钮后端接口必须每条都校验我把这类判断统一封在一个DataScopeHelper里凡是涉及写操作都调用它防止漏加。另外还有一个比较隐蔽的细节学生浏览岗位列表时看不到企业完整联系方式只有投递被企业“已查看”或“已录用”后详情接口才返回手机号和微信。这个逻辑通过动态判断投递状态即可实现属于业务型数据权限写进接口文档里避免前端凭空猜测字段什么时候出现。4. 前端Vue3工程实践封装、状态管理和几个容易踩的坑后端逻辑再完整前端接不好体验也白搭。蜗牛兼职网的前端采用Vite Vue3 Pinia Element Plus这套常见组合整体难度不高但有几个点处理得好不好直接决定联调时翻不翻车。4.1 Axios封装统一错误处理与登录过期项目里所有接口都走一个封装好的request模块而不是每个页面单独引入axios发请求。这样做最大的价值在于统一了三件事Token注入、HTTP错误映射、业务码处理。const request axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL, timeout: 10000 }) request.interceptors.request.use(config { const token useAuthStore().token if (token) config.headers.Authorization token return config }) request.interceptors.response.use( response { const res response.data if (res.code 200) return res if (res.code 401) { useAuthStore().logout() router.push(/login) return Promise.reject(new Error(登录已过期)) } ElMessage.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) }, error { ElMessage.error(error.message || 网络异常) return Promise.reject(error) } )这块代码看起来平淡实际上有个高频问题401弹窗重复出现。比如列表页同时发三个请求三个请求都因为Token过期返回401拦截器里连续执行三次logout和三次router.push页面会跳来跳去报错提示弹满屏幕。我的处理方法是引入一个isRefreshing标记和等待队列只让第一个401请求触发重新登录逻辑其余请求排队等待刷新结果。如果刷新Token成功把排队的请求用新Token重新发起如果刷新失败再统一跳登录页。这种并发去重机制在真实项目里用太频繁了但很多资料里不讲属于典型的“代码看得懂、遇事不会用”。4.2 Pinia状态管理只把真正的全局状态放进去Vue3推荐用Pinia管理状态但并非所有数据都该塞进store。如果你把每个页面的搜索条件都放进store页面刷新后还要想办法恢复状态纯属给自己加戏。蜗牛兼职网里我主要放了三类内容token、用户基本信息、未读消息数。这些数据的特点是“几乎每个页面都要用”且“变化会影响所有页面”。至于岗位列表、投递记录这些页面私有数据留在组件内部或临时缓存即可不需要全局共享。Pinia的store里还有一个容易被忽略的问题跨标签页同步。用户在一份浏览器里开两个标签登录同一个账号一边修改了头像另一边可能还是旧缓存。这个问题不需要做完整的跨标签通信简单方案是在请求成功修改个人资料后主动调用一个fetchUserInfo刷新store并在store里比较更新时间。要更极客一点可以用storage事件监听token变化但对我这边项目来说前者已经足够。4.3 路由守卫动态权限与公开页面白名单前端路由不能当作安全边界但它直接影响用户体验。蜗牛兼职网采用静态路由表所有页面写在Routes配置里再通过meta.requiresAuth和meta.roles做访问控制。router.beforeEach((to, from, next) { const authStore useAuthStore() if (to.meta.public) { next() return } if (!authStore.token) { next({ path: /login, query: { redirect: to.fullPath } }) return } if (to.meta.roles !to.meta.roles.includes(authStore.roleCode)) { next({ path: /403 }) return } next() })这里有个细节值得展开用户手动访问一个不属于自己身份的页面时应该跳转到403页面而不是404。很多人习惯把所有不认识的路径直接引向404然后在排查问题时分不清是页面没写还是权限没配。区分开用一句话就能定位问题。5. 联调阶段实测笔记六个我几乎每次都会踩的坑这部分是全文最有操作价值的内容。下面每个问题都来自真实联调场景我给的不是一句话答案而是完整的排查链路方便你遇到类似情况时能顺着思路走。5.1 MySQL8.0连接时报Public Key Retrieval is not allowed现象SpringBoot项目启动后台日志报java.sql.SQLNonTransientConnectionException: Public Key Retrieval is not allowed。排查过程我第一反应是驱动版本不对把mysql-connector-java从5.1.49换成8.0.33问题依旧。后来查连接串发现url里只写了localhost:3306和数据库名。又对照8.0的官方文档才确认是caching_sha2_password认证插件导致的。根治方式JDBC连接串里加上allowPublicKeyRetrievaltrue完事后建议同步加上useSSLfalse和serverTimezoneAsia/Shanghai。前者是开发环境下方便调试后两者是保证SSL验证不打扰本地连接、时区不偏差8小时。这三行参数配上再没见过这类启动报错。提示allowPublicKeyRetrievaltrue在生产环境要谨慎开启因为它允许客户端在建立连接时向服务端申请公钥。如果对传输安全要求高推荐用SSL方式或配置正确的证书而不是用这个开关。5.2 LocalDateTime字段传给前端出现一串数字现象数据库里存的发布时间在接口返回里变成了一大串数字前端拿到后格式化失败。排查过程看JSON数据日期字段被序列化成了时间戳。原因是Jackson默认不认识和LocalDateTime或者项目中没配置JavaTimeModule和禁用WRITE_DATES_AS_TIMESTAMPS。我最初只在application.yml里设了spring.jackson.date-format但那是针对java.util.Date的对java.time包无效。根治方式使用Jackson的自定义配置或者直接给实体类字段上加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)。推荐前者全局配置一次所有LocalDateTime字段都生效。spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8同时新建一个JacksonConfig注册JavaTimeModule并且不把日期序列化为时间戳。两处配置配合前端的dayjs格式化压力小很多。5.3 MyBatis-Plus的updateById更新不了null字段现象学生把简历里的“个人简介”清空保存成功后重新查询发现字段还是旧值。排查过程第一反应是前台传参少了打开Network面板发现请求体里确实有introduction: 。再看后端接口接收对象里的introduction是空字符串而不是null按理说应该能更新。最后才想到MyBatis-Plus默认的字段策略是NOT_NULL也就是只更新非null字段空字符串虽不是null但String字段再配合策略容易出现字段被忽略的混淆情况。根治方式对这个字段使用TableField(updateStrategy FieldStrategy.IGNORED)或者将实体类全局字段策略改成IGNORED。我建议只在特定字段上处理因为全局放开后每次update都会把所有字段拼进SQL既影响性能又容易误更新。提示这里要注意区分两个场景。用户把字段完全清空前端传的是空字符串要让它更新用户根本没传这个字段对象里是null通常应该忽略。所以更精细的方案是DTO里单独标志哪些字段需要强制更新而不是一刀切处理。5.4 分页查询的total总数和实际记录数对不上现象岗位列表用了JOIN查询关联分类表和企业表分页正常但total有时候多出来有时候变小。排查过程MyBatis-Plus分页插件在处理JOIN查询时自动生成的count语句会简单地对主查询包一层select count(*) from (...)这种写法在有些JOIN场景下会把笛卡尔积带进count导致总数虚高。我最初通过手动指定countSql解决后来又发现只要把主SQL和countSql分开优化就可以。根治方式在Mapper的XML里手动写count语句。分页插件允许你在方法上用Select注解或XML方式显式提供count语句别依赖自动生成的。把JOIN条件里的多余字段去掉count语句只统计主表id去重后的数量。select idselectJobPage resultTypecom.demo.dto.JobVO SELECT j.id, j.title, c.name AS companyName, t.name AS categoryName FROM job_post j LEFT JOIN company_profile c ON j.company_id c.user_id LEFT JOIN job_category t ON j.category_id t.id WHERE j.deleted 0 AND j.status PUBLISHED /select select idselectJobPageCount resultTypelong SELECT COUNT(DISTINCT j.id) FROM job_post j WHERE j.deleted 0 AND j.status PUBLISHED /select5.5 修改用户资料后自动填充字段被重置现象更新昵称后createTime竟然变成了当前时间数据库里的历史创建记录被覆盖了。排查过程看实体类里createTime和updateTime都配了MyBatis-Plus的自动填充注解TableField(fill FieldFill.INSERT_UPDATE)。意思是插入和更新都会触发填充逻辑。createTime字段本应该只在插入时填充一次现在却被错误的策略带进去每次update都刷新了。根治方式把createTime改成fill FieldFill.INSERTupdateTime才能用INSERT_UPDATE。同时检查MetaObjectHandler的实现里是否用strictInsertFill和strictUpdateFill分别做了处理不要在更新逻辑里把createTime也塞进来。Component public class MyMetaObjectHandler implements MetaObjectHandler { Override public void insertFill(MetaObject metaObject) { this.strictInsertFill(metaObject, createTime, LocalDateTime.class, LocalDateTime.now()); this.strictInsertFill(metaObject, updateTime, LocalDateTime.class, LocalDateTime.now()); } Override public void updateFill(MetaObject metaObject) { this.strictUpdateFill(metaObject, updateTime, LocalDateTime.class, LocalDateTime.now()); } }5.6 前端页面路由刷新后404现象部署到服务器nginx配置了静态资源和反向代理。用户从岗位列表页点击进入详情页刷新一次nginx报404。排查过程Vue Router用的history模式页面路径是前端路由不是真实文件路径。nginx默认只按静态文件定位刷新详情页时它去磁盘找/site/detail.html找不到就404。第一反应是改hash模式但URL带#号不美观和我预期不符。根治方式配nginx的try_files指令把所有非静态文件请求回退到index.html由前端路由接管。location / { root /opt/snail-web/dist; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }6. 打包部署与验收清单让项目真正可交付项目写完了、本地跑通了离“可交付”还有一步。很多课设和简历项目倒在这一步——代码能run但部署包不完整环境的差异一换就崩。下面是我自己固定使用的一套流程和检查项。6.1 前端构建与后端打包顺序蜗牛兼职网是前后端分离的。前端开发时通过Vite代理访问后端8080端口但部署时有两种常见方式一种是前端和后端完全分开部署前端用nginx提供静态文件后端只暴露API另一种是把前端build出来的dist目录直接复制到后端resources/static下做成单一SpringBoot jar运行。我更推荐第一种因为它让接口层和页面层各自独立。运维上只要改nginx配置就能换前端静态文件后端升级不用动前端。而且如果以后要扩展小程序或App后端API可以直接复用不用再抽一层。前端打包需要注意环境变量。构建前要确保.env.production里的VITE_API_BASE_URL指向可被浏览器访问到的API地址。如果部署在云服务器这里应该填公网域名或服务器IP而不是localhost否则用户在浏览器里请求的地址指向他自己电脑。npm run build mvn clean package -DskipTests后端打包时建议跳过测试避免本地数据库连接不上导致构建失败。打包完成后看jar包大小正常应该包含依赖和配置大概几十MB。6.2 上线前的自测清单这个清单我每次交付前都会过一遍推荐你直接照着抄一份检查项操作动作预期结果登录过期登录后等Token过期再操作页面跳转登录页数据不残留越权访问学生Token调用企业下架接口返回403数据不变更空数据处理岗位列表在无数据时访问页面显示空状态不报错并发投递两账号同时投递同一岗位投递表无重复脏数据文件上传上传超大图片或非法格式后端拒绝前端提示逻辑删除删除岗位后再分页查询列表不出现数据库记录仍存在时间时区服务器切换时区后访问页面时间与本地一致弱口令注册输入纯数字或超短密码校验拦截提示密码强度6.3 文档的价值从“跑起来的项目”到“能参考的系统”标题里特意强调了【含文档】这一点我多说两句。源码再完整如果没有数据库初始化脚本、接口文档和部署说明后来接手的同学基本无从下手。建议交付包至少包含完整的SQL初始化脚本含建库建表、初始管理员账号、基础数据、Postman或Apifox导出的接口测试集、部署环境说明JDK版本、Node版本、MySQL版本、nginx配置示例、以及一个记录疑难问题的FAQ文档。文档不是写给答辩老师看的是写给三个月后的自己看的。我刚做类似系统时也嫌文档累赘等到回读自己代码时才发现当初的设计意图全靠文档才能快速还原。说句实在话有这份文档的价值和没有这份文档的项目在真实工程里完全不是一个等级。整个项目从需求拆解、技术选型、后端状态机、前端封装到最后部署验收每一条线都可以单独深挖。蜗牛兼职网这套源码如果只用来“跑起来看效果”多少有点浪费把它拆开对照着业务点逐层看才是收获最大的方式。真动手改几行代码再跑一遍测试比抱着源码看三遍都有用。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
