SpringBoot+Vue3+MyBatis就业管理系统全栈开发实战-代码聚汇网

每年毕业季，高校辅导员手动统计就业信息的方式早就跟不上节奏了。我去年帮朋友做了一套就业管理系统，技术栈正是标题里这套：Java SpringBoot+Vue3+MyBatis+MySQL，前后端分离部署，目前已经在他们学院稳定跑了大半年。这系统说复杂不算复杂，但麻雀虽小五脏俱全——登录鉴权、多角色权限、新闻公告、招聘信息、投递记录、就业统计报表全都有，几乎覆盖了一个Web全栈项目该有的所有核心知识点。这套源码对两类人特别有价值：一是正在准备毕业设计、想搞一套能答辩能演示的完整系统的人，二是想系统学习前后端分离开发模式、但不想从零开始造轮子的Java学习者。

关于这套系统本身，我用一句话概括它的核心价值：它不是一个只摆样子的CRUD Demo，而是一个把权限模型、动态SQL统计、多角色交互都串起来的完整业务闭环。接下来我把这个项目从设计思路到前后端实现、再到踩坑记录，一层层拆开讲清楚。

1. 就业管理系统的功能全景：不只是录入信息那么简单

很多初次接触这类系统的人容易陷入一个误区：觉得就业管理系统就是"学生填个就业信息、老师看一眼统计"，做个增删改查不就完了？真做起来会发现完全不是这么回事。就业管理本质上是一个多角色、跨部门流转的业务流程，涉及学生、辅导员、院系管理员、校级管理员四类角色的相互协作。

我设计这套系统时，把功能模块按角色拆成了三块：

学生端功能：

个人简历维护（基本信息、教育经历、技能证书、求职意向）
浏览招聘公告和企业发布的岗位信息
投递简历并查看投递状态（待审核、已通过、已拒绝）
填写就业登记（就业单位、岗位、薪资、就业去向）

教师端功能：

审核学生提交的就业登记数据
审核简历投递状态
按班级、专业、年级维度查看就业进度
发布就业指导公告

管理端功能：

用户管理（账号开通、角色分配、密码重置）
招聘企业管理与岗位审核
就业率数据看板（按专业、班级、学历多维度统计）
系统参数配置（毕业年份、专业目录维护）

这套模块设计逻辑是：数据从学生端产生，经过教师端审核校验，最终汇总到管理端的统计看板，每一层都对上游数据做一次"质量过滤"。实际操作中很多同学做毕设只做了管理端，觉得"我是管理员，让管理员一个人录所有数据"就行——这恰恰是最不真实的设计。真实场景里数据量一大，管理员根本录不过来，而且就业数据必须由学生本人确认、辅导员审核，这个流程本身就是业务的一部分。

从技术角度讲，上述功能完整覆盖了后端开发中最高频的三类技能：RBAC权限控制、一对多关联查询、GROUP BY聚合统计。这三块恰恰是Java面试中问得最多的DB操作场景。所以说，这套系统当成毕业设计做出来，答辩时能讲的东西会很扎实，不愁没内容可讲。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 技术选型为什么是这套组合：每个组件的角色与取舍逻辑

聊完功能，得说说技术选型。SpringBoot+Vue3+MyBatis+MySQL这套组合如今已经是国内Web开发最主流的"默认选项"，但很多人只是"大家都在用所以我也用"，讲不出每个组件在这个系统里的具体价值。我当时做选型时的思考过程，大致如下。

2.1 SpringBoot：把工程复杂度关进笼子

SpringBoot承担的是后端基础设施的职责——HTTP请求接收、路由分发、事务管理、参数校验、统一异常处理。选它而不是传统的SSH（Struts+Spring+Hibernate）或纯Servlet，核心原因是自动配置机制。比如你要引入一个分页插件、一个参数校验框架，加依赖再加上对应的@Configuration或@EnableXXX注解即可，大幅降低了繁琐的XML配置成本。

SpringBoot 3.x之后要求JDK 17起步，如果你是做毕业设计的新手，我的建议是直接上SpringBoot 2.7.x + JDK 1.8或8，原因后面会详细讲。别小看这步选择，版本不匹配导致的报错是这类项目最先遇到的一道坎。

2.2 Vue3 + Vite：前端的开发效率担当

前端选Vue3的原因很直观：Vue在国内生态积累深，Element Plus组件库对中后台系统的覆盖度之高，几乎到了"你想要的组件它都有"的程度。Vue3相比Vue2最核心的变化是Composition API，它把一组相关的状态和逻辑聚合在一起，代码复用比Options API的mixin方式更清晰。

这套系统里，尾部的axios请求、登录状态的维护、动态路由的生成我是全部用Composition API重写的。举个例子，封装一个useTableList组合式函数，把表格加载、分页、条件筛选的状态和逻辑都放进一个函数里，列表页的代码量直接少了一半。这在Vue2时代是不可想象的。

脚手架我选的是Vite而不是Vue CLI，核心原因是速度。Vite基于ES Module的开发服务器，冷启动和热更新都是毫秒级响应，对开发体验的提升非常明显。老项目迁移到Vite有个坑，就是Node版本要求比较高，Vite 4要求Node 14.18+，Vite 5要求Node 18+，这块装环境时要提前确认。

2.3 MyBatis：SQL亲手掌控的无价优势

ORM框架里JPA和MyBatis之争从来没有停止过，我在这套系统里选MyBatis，核心考量就一条：就业统计报表的SQL复杂度太高，用JPA这类框架表达聚合查询时极度别扭。

比如"统计各专业就业率"，SQL要同时关联学生表、就业登记表、专业表，还要按年份过滤、按就业状态分组，计算已就业人数和总人数。用JPA写这种查询，要么写JPQL，要么直接用原生SQL，复杂度一点没降。用MyBatis则可以直接把SQL攥在手里，所有查询逻辑一目了然，还能配合动态SQL做条件拼装。

另外，MyBatis对复杂结果映射的支持也是我从不敢放手JPA去做的原因。一个招聘信息关联多个岗位、一个学生关联多段教育背景，这种嵌套查询和关联映射是MyBatis的看家本领。如果你以后工作要对接报表系统、数据中台这类重SQL场景，MyBatis的经验是刚需。

2.4 MySQL 8.0：兼顾稳定与性能的默认答案

数据库层面几乎没有悬念，MySQL 8.0是当前最稳妥的选择。8.0相比5.7有几个关键提升：默认字符集改为utf8mb4、支持窗口函数、支持公用表表达式（CTE）、查询优化器更强。这套系统里的就业率统计，如果要按年月做趋势对比，窗口函数LAG()能省掉很多自连接的麻烦。

实际做这套系统时要注意一个MySQL连接的高频坑：SSL连接错误。使用MySQL 8.0和较新的JDBC驱动时，连接串不配useSSL=false很容易报Communications link failure，这个问题网上讨论很多，其实解决方法就一行参数，后面联调章节我会再讲。

2.5 前后端分离：开发协作模式带来的工程化红利

前后端分离不是新概念，但这套系统让我体会最深的是并行开发的自由度。我前端用Vite的dev server跑在5173端口，后端SpringBoot跑在8080端口，开发时通过Vite的proxy配置把/api前缀的请求转发到后端，完全不用等对方、互不阻塞。这种模式下，前端只关心数据结构和交互，后端只关心接口定义和业务逻辑，中间通过一份Swagger/API文档对齐。

不过，前后端分离也带来了一个经典麻烦——跨域。开发阶段用proxy轻松绕过去了，生产阶段如果前后端分别部署在不同域名或端口，就必须靠Nginx反向代理来统一入口。我在部署章节会给出完整的Nginx配置，照着抄就行。

3. 环境准备与项目初始化：从零到能跑通前后端的关键细节

这部分我写得细一些，因为我把这套源码发给过不下十个同学，发现大家卡在环境配置上的时间，比写代码还长。环境问题最大的特点就是：报错信息千奇百怪，但根因往往就那么几个。

3.1 JDK、Maven、Node、MySQL的版本搭配清单

先给出一套我验证过可以稳定运行的版本组合：

组件	推荐版本	注意事项
JDK	8（对应SpringBoot 2.7.x）或17（对应SpringBoot 3.x）	二选一，别混用
Maven	3.6.3+	配置阿里云镜像加速依赖下载
Node.js	18 LTS	Vite 4/5都要求Node 18+，太老会有兼容问题
MySQL	8.0	5.7基本也兼容，但窗口函数用不了
SpringBoot	2.7.18	稳定，Java 8可直接跑，避免高版本适配问题

这里重点提醒一个年轻人常踩的坑：SpringBoot版本不是越新越好。SpringBoot 3.x全面切换到Jakarta命名空间（javax.*变成jakarta.*），很多教程和老的整合代码全部失效。我们做系统、做毕设追求的是顺利跑通，选2.7.x + JDK 8是性价比最高的组合。除非你要解决的问题非得用SpringBoot 3的新特性，否则没必要在版本适配这种无意义的事上消耗时间。

3.2 MySQL初始化与编码：最早埋下的隐患

数据库初始化这一块，大多数教程只会说"导入sql文件"，但有两个细节我必须单独拎出来讲：

第一是字符集。建库时一定要用utf8mb4，而不是utf8。原因是utf8在MySQL里最多存3个字节，像一些冷门生僻字和Emoji表情根本存不进去，用户简历里如果填了个特殊符号，插入就直接报错。正确的建库语句是：

sql复制CREATE DATABASE employment_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

第二是数据库连接的SSL问题。MySQL 8.0默认开了SSL，但很多本地开发环境的证书配置并不可靠，项目启动时连接数据库会报SSL connection error。在application.yml里把连接串改成下面这个格式，这个坑就绕过去了：

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/employment_system?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai

serverTimezone=Asia/Shanghai这个参数也很关键。我遇到过系统里新增记录的时间比本地时间多了8小时的情况，排查了半天，罪魁祸首就是JDBC驱动默认取UTC时区，导致时间偏差。加上时区参数后所有时间问题一次解决。

3.3 后端工程搭建：从Spring Initializr开始的骨架

后端的骨架搭建我推荐用Spring Initializr（start.spring.io）生成基础工程，比手动建目录省事得多。生成时勾选以下依赖：

Spring Web（做接口层）
MyBatis Framework（数据库操作）
MySQL Driver（MySQL驱动）
Lombok（省掉实体类的getter/setter）
Validation（参数校验）

生成后补一个Java JWT库和Hutool工具包（封装了非常多实用工具，包括文件上传、日期处理、加密算法等），一个后端的可用骨架就齐了。工程目录结构我是这样划分的：

code复制com.example.employment
├── controller    # 接口层
├── service       # 业务层
├── mapper        # MyBatis的Mapper接口
├── entity        # 实体类
├── dto           # 数据传输对象
├── vo           # 视图对象
├── config       # 配置类（拦截器、跨域、Redis等）
├── common       # 通用类（返回值封装、异常处理、枚举）
└── utils        # 工具类

这里说一个新手常犯的问题：把业务逻辑全部写在Controller里，接口几百行，完全没分层。分层不只是为了好看，分层设计直接决定了后续维护和代码复用的难度。系统里"发布招聘信息"这个操作，涉及创建企业记录、关联岗位、记录操作日志三件事，全部堆在Controller里的话，以后想在别的地方复用就抓瞎了。分层做的好的项目，Service可以随时被其他模块按需调用。

3.4 前端工程搭建：Vite脚手架的快速起手

前端用Vite的脚手架命令直接生成Vue3工程：

bash复制npm create vite@latest employment-web -- --template vue
cd employment-web
npm install
npm install vue-router@4 axios element-plus @element-plus/icons-vue

这里我的建议是不要用Vite脚手架默认的vue模板，而直接用带vue-router的模板参数，省得后面手动加路由文件。Element Plus的引入方式，开发阶段用完整引入最快，上线前再考虑按需引入的性能优化：

javascript复制// main.js
import ElementPlus from 'element-plus'
import 'element-plus/dist/index.css'

app.use(ElementPlus)

Vue3工程跑起来后，紧接着要做两件事：第一，在vite.config.js里配置开发代理；第二，封装axios请求实例。这两步是后续所有前端功能的地基，我在第五章会展开细讲。

4. 数据库设计与后端核心实现：写代码之前先把表结构想明白

一套系统是否耐看，数据库设计占了六成功力。我见过不少半途推翻重做的项目，翻来覆去就是前期表设计没想清楚。就业管理系统涉及用户认证、简历、岗位、投递、审核、统计等场景，表结构设计时我建议把注意力集中在两个核心模型上：用户权限模型和就业登记数据模型。

4.1 用户表设计：用类型字段而非拆表来实现多角色

很多人在设计"学生、老师、管理员"这三种角色时，下意识地建了三个表。这个方案的问题在于：所有角色都有共同的登录凭证（用户名、密码、状态），拆成三表会让登录校验逻辑冗余且难维护。

我这里用的是单用户表 + 角色字段的方案：

sql复制CREATE TABLE sys_user (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    username VARCHAR(50) UNIQUE NOT NULL COMMENT '登录名',
    password VARCHAR(100) NOT NULL COMMENT '密码（BCrypt加密）',
    real_name VARCHAR(50) NOT NULL COMMENT '姓名',
    role_type TINYINT NOT NULL COMMENT '角色：1学生 2教师 3管理员',
    college_id BIGINT COMMENT '所属院系ID',
    major_id BIGINT COMMENT '所属专业ID（学生）',
    class_id BIGINT COMMENT '所属班级ID（学生）',
    status TINYINT DEFAULT 1 COMMENT '1启用 0禁用',
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP
);

角色字段role_type配合后端拦截器做权限控制，一个接口一个注解，干净利落。如果后续要扩展角色（比如企业用户、实习导师），只需加一个枚举值，不必动表结构设计。

密码字段我强制用BCrypt加密存储。BCrypt的加密特点是相同的明文每次加密结果都不同，而且自带加盐逻辑，即使数据库泄露，明文密码也难以反推。工具类在Spring Security里可以直接引入，但为了不引入整个Security框架过重的权限体系，我们只引入了spring-security-crypto这个轻量模块，单独调用BCrypt加密。这样登录逻辑还是我们自己控制，又保留了密码的安全性。

4.2 就业登记数据模型：统计报表灵活性的根基

就业登记表是这套系统的统计核心，设计时需要考虑到后续大量汇总查询的需求：

sql复制CREATE TABLE employ_registration (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    student_id BIGINT NOT NULL COMMENT '学生ID',
    company_name VARCHAR(200) COMMENT '单位名称',
    company_type VARCHAR(50) COMMENT '单位性质：国企/私企/外企/事业单位',
    job_position VARCHAR(100) COMMENT '岗位名称',
    salary_range VARCHAR(50) COMMENT '薪资范围',
    sign_date DATE COMMENT '签约时间',
    employment_status TINYINT DEFAULT 0 COMMENT '0未就业 1已就业 2灵活就业 3自主创业',
    audit_status TINYINT DEFAULT 0 COMMENT '0待审核 1通过 2驳回',
    auditor_id BIGINT COMMENT '审核人ID',
    audit_time DATETIME COMMENT '审核时间',
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
    update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

这里的关键决策是：统计口径字段全部落表，而不是运行时去关联字典表。以company_type为例，虽然可以在字典表里维护，但从查询性能角度，统计时直接GROUP BY company_type就能拿到各个性质单位的占比，不必每次跑JOIN。数据冗余一些，换来的是代码逻辑简单、报表查询快速。实际业务中，就业率统计不仅要按单位性质分，还要按专业分、按班级分、按签约时间段分，"口径字段落表"的设计方案能保证无论从哪个维度切，SQL构造都足够轻松。

4.3 MyBatis的核心配置：驼峰映射、分页插件、动态SQL

MyBatis用得好的关键在配置。三个最重要的配置点如下：

驼峰映射：把数据库下划线字段名自动映射到实体类驼峰属性，避免手写大量的resultMap：

yaml复制mybatis:
  configuration:
    map-underscore-to-camel-case: true

分页插件：用的PageHelper，它是国内最流行的MyBatis分页插件，底层就是拦截器改写SQL：

java复制PageHelper.startPage(pageNum, pageSize);
List<StudentVO> list = studentMapper.selectStudentList(condition);
PageInfo<StudentVO> pageInfo = new PageInfo<>(list);

这里有个坑必须提醒：PageHelper.startPage()只对紧接着的下一条查询语句生效。如果在调用Mapper之前又执行了其他SQL（比如查字典、查缓存），分页就会串到别的查询上，数据莫名其妙就少了一截。这是我实际踩过的问题，排查了很久才定位。

批量插入：招聘信息一次可能有多个岗位，用XML的foreach标签可以轻松实现批量插入：

xml复制<insert id="batchInsertPositions">
    INSERT INTO job_position (job_id, position_name, requirement)
    VALUES
    <foreach collection="list" item="item" separator=",">
        (#{item.jobId}, #{item.positionName}, #{item.requirement})
    </foreach>
</insert>

批量插入不仅代码好看，性能也比循环单插高一个数量级。数据库层面，MySQL JDBC连接串加个rewriteBatchedStatements=true参数，批量插入性能还能再提一倍，这个参数容易被忽略，但它确实值得写进配置文件里：

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/employment_system?rewriteBatchedStatements=true&useSSL=false

4.4 核心接口实现：登录、Token鉴权、就业率统计

登录接口全链路实现如下：

java复制@PostMapping("/login")
public Result login(@RequestBody @Valid LoginDTO dto) {
    // 1. 根据用户名查询用户
    SysUser user = userMapper.selectByUsername(dto.getUsername());
    // 2. 校验密码（BCrypt匹配）
    if (user == null || !BCrypt.checkpw(dto.getPassword(), user.getPassword())) {
        return Result.error("用户名或密码错误");
    }
    // 3. 校验状态
    if (user.getStatus() == 0) {
        return Result.error("账号已被禁用，请联系管理员");
    }
    // 4. 生成JWT Token
    String token = JwtUtil.createToken(user.getId(), user.getRoleType());
    // 5. 返回用户信息（脱敏处理）
    return Result.success(new LoginVO(token, user));
}

Token鉴权我用的是过滤器+拦截器组合。过滤器负责从请求头取出Token，拦截器负责校验白名单路径（登录接口、注册接口不拦截），核心代码：

java复制public class JwtInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
        // 预检请求直接放行
        if ("OPTIONS".equals(request.getMethod())) return true;
        String token = request.getHeader("Authorization");
        if (StringUtils.isBlank(token)) {
            throw new BusinessException(401, "未登录或登录已过期");
        }
        Claims claims = JwtUtil.parseToken(token.replace("Bearer ", ""));
        request.setAttribute("userId", claims.get("userId"));
        request.setAttribute("roleType", claims.get("roleType"));
        return true;
    }
}

这里有一个非常实用的细节：拦截器里不做数据库查询，只从Token里解析用户身份。用户信息在登录时已经写入Token，后续请求直接解析即可，省掉每次请求都查一次用户表的开销。要获取最新的用户信息时，再按需查询。

就业率统计接口，这条SQL是整套系统的精髓：

xml复制<select id="countEmploymentRateByMajor" resultType="map">
    SELECT
        m.major_name AS majorName,
        COUNT(u.id) AS totalCount,
        SUM(CASE WHEN er.id IS NOT NULL AND er.employment_status = 1 THEN 1 ELSE 0 END) AS employedCount,
        ROUND(
            SUM(CASE WHEN er.id IS NOT NULL AND er.employment_status = 1 THEN 1 ELSE 0 END) / COUNT(u.id) * 100, 2
        ) AS rate
    FROM sys_user u
    LEFT JOIN major m ON u.major_id = m.id
    LEFT JOIN employ_registration er ON u.id = er.student_id AND er.audit_status = 1
    WHERE u.role_type = 1
    <if test="collegeId != null">
        AND u.college_id = #{collegeId}
    </if>
    <if test="year != null">
        AND YEAR(er.sign_date) = #{year}
    </if>
    GROUP BY m.major_name
    ORDER BY rate DESC
</select>

这条SQL看起来长，但拆解开就是几个要点的组合：LEFT JOIN保留所有学生（包括未登记就业的）、CASE WHEN条件计数实现按状态聚合、ROUND算出比率、<if>动态拼装筛选项。写MyBatis动态SQL的思路就是"先写好一条能跑的最简SQL，再把可变条件用if标签替换"，没必要一开始就写最全版本，那样容易被语法错误劝退。

4.5 多角色权限控制的落地细节

角色权限这块，我没引入Spring Security或者Shiro框架，采用的是最轻量的方案：拦截器 + 注解。

定义注解：

java复制@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface RequiresRole {
    int[] value();
}

在需要权限控制的方法上加上注解：

java复制@RequiresRole({1, 2}) // 学生和教师可访问
@GetMapping("/myRegistrations")
public Result myRegistrations() {
    Long userId = (Long) request.getAttribute("userId");
    ...
}

拦截器里解析注解做放行判断：

java复制// 在preHandle中补充角色校验
RequiresRole requiresRole = handlerMethod.getMethodAnnotation(RequiresRole.class);
if (requiresRole != null) {
    Integer roleType = (Integer) request.getAttribute("roleType");
    if (!Arrays.asList(requiresRole.value()).contains(roleType)) {
        throw new BusinessException(403, "权限不足");
    }
}

这个方案的权衡我很清楚：它无法做到接口级的细粒度数据权限，但在中小型系统中完全够用。真要引入Spring Security全家桶，光是配置过滤器链、自定义认证管理器、配置方法级权限，就能让一个毕设项目的复杂度上升一个档次。系统设计永远是取舍，不是堆料，把精力放在核心业务上，会让开发效率高得多。

5. Vue3前端的关键实现：从登录鉴权到动态路由的全流程

前端部分的工程实践，我挑几个最有含金量的实现细节重点讲。前端做得好不好，直接影响项目演示时的观感——这也是为什么同一个后端，有人做出来的系统给人感觉很专业，有人做出来像课设Demo，差异基本都在前端交互细节上。

5.1 Axios封装：注入Token、统一错误提示、401跳转

axios的封装是前端工程质量的分水岭。未经封装的页面里，每个请求都要手动带Token、手动处理错误弹窗，代码量成倍膨胀且极易出Bug。我的统一封装方案如下：

javascript复制// src/utils/request.js
import axios from 'axios'
import { ElMessage } from 'element-plus'
import router from '@/router'

const request = axios.create({
  baseURL: '/api',
  timeout: 10000
})

// 请求拦截器：注入Token
request.interceptors.request.use(config => {
  const token = localStorage.getItem('token')
  if (token) {
    config.headers.Authorization = `Bearer ${token}`
  }
  return config
})

// 响应拦截器：统一处理错误
request.interceptors.response.use(
  response => {
    const res = response.data
    if (res.code !== 200) {
      ElMessage.error(res.message || '请求失败')
      return Promise.reject(new Error(res.message))
    }
    return res.data
  },
  error => {
    if (error.response?.status === 401) {
      localStorage.removeItem('token')
      router.push('/login')
    }
    ElMessage.error(error.response?.data?.message || '网络异常')
    return Promise.reject(error)
  }
)

export default request

这里有两个细节值得说明：第一，响应拦截器里我把res.data直接返回给调用方，业务代码里拿到的就是纯净的业务数据，少了一层.data.data包裹；第二，401统一清除登录态并跳转登录页，这个逻辑必须放在拦截器层做，否则每个页面都要自己判断一遍。Token存localStorage是权衡后的选择——更安全的是存内存+刷新重新获取Token，但对中小型系统来说，localStorage的持久登录体验更友好。代价是如果前端代码被注入恶意脚本，Token存在泄露风险，所以这类系统一定不能接入来历不明的第三方脚本，安全底线要守住。

5.2 路由守卫与动态路由生成

Vue3里做登录鉴权和动态路由是绕不开的环节。路由守卫的目的是：未登录用户访问受保护页面时，直接踢回登录页。

javascript复制// src/router/index.js
router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token')
  const roleType = Number(localStorage.getItem('roleType'))

  if (to.path === '/login') {
    if (token) return next('/')
    return next()
  }

  if (!token) {
    return next('/login')
  }

  // 已登录但角色对应的路由尚未注册
  if (!router.hasRoute(to.name)) {
    const dynamicRoutes = generateRoutes(roleType)
    dynamicRoutes.forEach(route => router.addRoute(route))
    return next({ ...to, replace: true })
  }

  next()
})

generateRoutes根据角色类型返回不同的路由表。比如学生端返回/student/register、/student/resume，教师端返回/teacher/audit，管理员返回/admin/dashboard。这样用户登录后，导航菜单和可访问页面就根据角色自动生成了，不需要后端额外下发菜单权限数据。

做这套动态路由的时候，还涉及一个"刷新丢路由"的坑：页面刷新后Vuex/Pinia里的路由数据清空，动态注册的路由全部丢失，跳转任何页面都会404。解决办法是在路由守卫里判断当前点击的路由是否已注册，未注册就先触发生成路由再放行。我上面的代码里router.hasRoute(to.name)加next({ ...to, replace: true })就是干这个的，这是我写过几版之后才稳定下来的一套处理方案。

5.3 文件上传：简历附件的两种处理方式

就业系统必然涉及简历上传的场景。上传方案有两个维度：如果项目只做演示，可以存本地磁盘；如果追求生产可用，应该上OSS对象存储。针对后端的处理方式，我的建议是存OSS，但为了演示简便，我这里实现的是存本地磁盘+静态资源映射的方案。

前端用Element Plus的上传组件：

vue复制<el-upload
  action="/api/common/upload"
  :headers="uploadHeaders"
  name="file"
  :on-success="handleUploadSuccess">
  <el-button type="primary">上传简历</el-button>
</el-upload>

后端的Controller：

java复制@PostMapping("/common/upload")
public Result upload(@RequestParam("file") MultipartFile file) {
    // 校验文件类型和大小
    String originalFilename = file.getOriginalFilename();
    long maxSize = 5 * 1024 * 1024; // 5MB
    if (file.getSize() > maxSize) {
        return Result.error("文件大小不能超过5MB");
    }
    // 生成存储文件名（防止文件名冲突和路径穿越）
    String ext = originalFilename.substring(originalFilename.lastIndexOf("."));
    String filename = UUID.randomUUID().toString().replace("-", "") + ext;
    String datePath = LocalDate.now().toString().replace("-", "/");
    File dir = new File(UPLOAD_DIR + "/" + datePath);
    if (!dir.exists()) dir.mkdirs();
    file.transferTo(new File(dir.getAbsolutePath() + "/" + filename));
    // 返回访问路径
    return Result.success("/files/" + datePath + "/" + filename);
}

注意这里有个容易忽略的安全细节：存储文件名不要用原始文件名。用户上传的文件名可能包含非法字符或恶意路径（比如../../evil.jsp），直接拼接会构成路径穿越漏洞。生成UUID文件名是最省心的防护方式。

SpringBoot的静态资源映射配置：

yaml复制spring:
  mvc:
    static-path-pattern: /files/**
  web:
    resources:
      static-locations: file:${upload.dir}

用file:前缀指向本机磁盘目录，前端就能通过http://localhost:8080/files/2025/03/xxx.pdf直接访问上传的文件。这也是前后端分离部署时的必要配置。

5.4 就业看板图表展示：ECharts让数据说话

管理端的就业率看板，我推荐用ECharts画图表。它提供的柱状图、饼图、折线图几乎覆盖了所有统计可视化需求，并且Vue3的封装方式非常简单：

vue复制<script setup>
import * as echarts from 'echarts'
import { onMounted, ref } from 'vue'

const chartRef = ref(null)
const chartData = ref({})

onMounted(async () => {
  chartData.value = await getEmploymentRate()
  const chart = echarts.init(chartRef.value)
  chart.setOption({
    xAxis: { type: 'category', data: chartData.value.majorNames },
    yAxis: { type: 'value' },
    series: [{
      type: 'bar',
      data: chartData.value.rates,
      itemStyle: { color: '#409EFF' }
    }]
  })
})
</script>

一个实用技巧：ECharts的图表实例要在onMounted钩子之后再初始化，因为此时DOM节点才渲染完成。如果你在created或setup阶段就调用echarts.init，大概率报"dom is null"错误，这个顺序问题常被新手踩到。

6. 前后端联调避坑实录：跨域、日期、空值和文件大小

联调阶段是这两个技术栈碰撞后问题最多的地方。我把实际项目中踩过的四类高频坑完整复盘一遍，这些坑任何一个都能卡住你几小时。

6.1 跨域问题：开发环境与生产环境的两种解法

开发环境用Vite的proxy解决，前端配置文件里加上：

javascript复制// vite.config.js
export default defineConfig({
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true
      }
    }
  }
})

这样前端请求/api/login会被代理转发到http://localhost:8080/api/login，跨域问题消失。关键是changeOrigin: true这个参数，如果缺了它，后端拿到的请求头里Host还是前端的地址，某些后端框架在做域名校验时会拒绝请求。

生产环境部署时，用Nginx做反向代理统一入口：

nginx复制server {
    listen 80;
    server_name yourdomain.com;

    # 前端静态资源
    location / {
        root /usr/share/nginx/html;
        try_files $uri $uri/ /index.html;  # 解决Vue Router history模式刷新404
    }

    # 后端API反向代理
    location /api/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

try_files那行是Vue Router使用history模式（地址栏没有#号）时的必备配置，否则刷新页面直接404。这是前端部署上线第一大坑。

6.2 日期格式序列化问题

前后端分离后，日期格式不统一的问题非常典型。后端返回的LocalDateTime默认序列化成"2025-03-12T10:30:00"，前端直接显示在表格里既不美观，表单回填时还可能解析失败。

我建议在application.yml里统一日期格式：

yaml复制spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

time-zone: GMT+8尤其重要，很多项目部署到Linux服务器后，日期显示差8个小时，根因就是服务器默认时区UTC，Jackson序列化时按UTC转换导致。加上这个配置后，前后端日期问题一次根治。

6.3 MyBatis的if标签空值判断

动态SQL的<if test="xxx != null">判断，有一个容易踩的坑：当参数为字符串""空串时，!= null判断通过，但实际查询条件变成了and major_id = ''，导致数据查不出来。正确的写法是：

xml复制<if test="majorId != null and majorId != ''">
    AND major_id = #{majorId}
</if>

这类问题是MyBatis动态SQL的经典陷阱，尤其在前端传了空字符串参数时频繁触发。我后来处理的方式是：前端请求参数在axios拦截器里统一清除空值，前端发出去的请求就没有多余的空参数，后端也不容易踩坑了。

6.4 上传文件大小限制：SpringBoot的默认1MB陷阱

SpringBoot对上传文件有一个默认大小限制，默认值1MB。学生传个带照片的简历PDF，动不动就是几MB，直接报FileSizeLimitExceededException。配置如下：

yaml复制spring:
  servlet:
    multipart:
      max-file-size: 10MB
      max-request-size: 10MB

max-request-size一定要跟着调大，如果一次上传多个文件，总请求体大小超过默认的10MB还是会被拦截。

7. 打包部署上线：前后端分离项目的本地联调与Nginx部署

系统开发完成之后，部署环节也是很多人的盲区。本地跑通了，不代表打包部署后还能跑通。这部分我把打包部署时容易踩的坑按顺序踩一遍。

7.1 后端打包与运行

后端打包用的是Maven：

bash复制# 跳过测试打包
mvn clean package -DskipTests

打包成功后，在target/目录下生成可执行的jar包，直接：

bash复制java -jar employment-system.jar

这里需要注意SpringBoot的多环境配置。开发环境用application-dev.yml，生产环境用application-prod.yml。启动时通过--spring.profiles.active=prod切换配置，生产环境的数据库密码、文件路径等敏感配置单独维护，防止开发配置泄到线上。

7.2 前端打包与部署

前端打包：

bash复制npm run build

打包产物在dist/目录，把它完整复制到Nginx的静态目录下（比如/usr/share/nginx/html），然后配置前面给过的Nginx反向代理就行。

这里有个关键步骤：前端打包前，一定要检查axios的baseURL配置。开发时是/api走代理，打包后如果直接请求根路径相对路径，可能会请求到Nginx的80端口下不存在的路径。保持baseURL: '/api'即可，因为Nginx已经把/api转发到后端了，这个链路在Nginx配置里已经闭环。

7.3 部署后的自检清单

部署完成后，我建议按下面的清单快速做一轮冒烟测试：

[ ] 访问前端地址，能正常打开登录页
[ ] 登录接口能通，看Nginx日志确认/api转发正常
[ ] 退出登录、刷新页面，路由不会404
[ ] 上传一个5MB左右的文件，确认文件上传正常
[ ] 就业统计图表有数据，日期显示没有8小时偏差
[ ] 数据库连接正常，看SpringBoot启动日志没有报错

这套清单覆盖了前后端分离部署最容易出问题的几个点，跑完一遍基本可以放心交付。

8. 从这套源码还能往哪里扩展：下一代就业管理系统的演进思路

系统做完不是终点，如果想让它具备更高的实用价值或面试谈资，有几个扩展方向值得考虑。

消息通知模块。目前学生的投递状态、审核结果都是被动查询，可以加一个站内信/系统通知模块。本地上可以用WebSocket做双向通信，学生投递简历后，教师端实时收到提醒，这是体验上很大的提升点。

AI简历诊断。现在大模型应用火热，可以接入大模型API做一个简单能力：学生上传简历后，自动解析简历文本内容，按完整度、关键词覆盖、格式规范性给出评分和改进建议。这个功能作为毕设的创新点是加分项，技术难度也不高，本质上一个HTTP调用加上Prompt工程的问题。

Excel导入导出。管理端老师最需要的功能其实是Excel批量导入学生信息和导出统计报表。用EasyExcel这个阿里开源的库，几十行代码就能实现复杂的Excel读写，这也是企业级系统的高频需求。

操作日志审计。管理员的增删改操作，特别是对用户信息的修改，都需要留痕。加一张操作日志表，配合一个AOP切面注解，访问和修改记录就都能自动记录下来，在真实系统中这个模块是合规刚需。

这些方向不需要推翻现有架构，全部是在现有SpringBoot+Vue3框架上做增量开发。选一个做下去，就能把一套毕设级的系统，变成一个有实战深度的完整作品。

我对这套系统最满意的一点是它的中庸——不是满身花哨技术，而是每一层都踩在JavaWeb开发最标准、最实用的位置上。前后端分离、RBAC权限、动态SQL统计、Token鉴权、文件处理、打包部署，这一套流程完整走下来，对SpringBoot和Vue3的实战理解会提升一个台阶。如果你正打算做类似的系统或者正在准备毕业设计，按照我上面拆解的这几个部分一步步推进，很快就能把一个功能完整、能演示、能答辩的系统跑起来。过程中遇到任何环境或联调问题，回头看第六节的避坑清单，大部分坑那里都有答案。

SpringBoot+Vue3+MyBatis就业管理系统全栈开发实战