SpringBoot+Vue科研工作量管理系统：环境搭建到二次开发实战

接手过一个SpringBoot+Vue的科研工作量管理系统，从源码结构、数据库脚本到接口文档，完整跑通、二次改造、成功答辩，整个过程踩了不少坑。这类Java Web毕设项目在市面上流传很广，但很多人拿到源码后第一步就卡在环境配置，更别提把前后端跑起来、看懂权限逻辑、改造成自己题目要求的样子。这篇就把这个项目的全貌拆开讲透，从业务场景到技术选型，从表结构设计到前后端联调，从SQL脚本怎么导到接口文档怎么看，全部讲明白，适合正在做毕设、想快速落地一个前后端分离项目的同学参考。

1. 科研工作量管理系统的业务本质

1.1 为什么需要一套科研工作量管理系统

科研工作量，说白了就是高校里老师每年都要报的“科研作业账”。论文发了几篇、专利授权了几个、课题结题了多少、成果获奖是什么级别，这些都需要在年底统一统计，用来算绩效、评职称、分配科研奖励。我接触过不少高校的实际情况，大部分还在用Excel表格人工汇总，科研秘书先发模板，老师们自己填，填完交上来，秘书再逐条核对、计算分值，最后汇总成全院报表。这个过程至少有三个痛点。

第一个痛点是格式不统一。有人填论文只写标题不写期刊级别，有人填专利不写授权号，有人把课题经费单位填成万元有人填成元。秘书要花大量时间打电话确认、反复退回修改。第二个痛点是核算规则容易出错。一篇论文是SCI还是核心、第一作者还是通讯作者、几个人合著，分值计算方式完全不同，人工套用规则经常出现争议。第三个痛点是数据没有留痕。去年的表找不到了，或者某位老师说自己当时提交过某条成果，但汇总表里没有，无从查证。

科研工作量管理系统解决的就是这三件事：统一录入入口、自动套用核算规则、全流程留痕可追溯。老师自己登录系统录入成果，系统校验格式和必填项；科研秘书在线审核，不合规的直接驳回并写明原因；系统根据预设的计分规则自动算分，生成个人和院系的工作量汇总表，支持导出Excel用于后续绩效分配。通用且刚需，这也是这类题目在毕设中长盛不衰的根本原因。

1.2 核心角色与业务闭环

要理解这个系统的代码，先要搞清楚系统里都有谁在干活。科研工作量管理系统通常包含四类角色，每类角色的权限边界和操作范围差异很大。

• 普通教师：录入个人成果、查看审核状态、查看个人工作量汇总。
• 科研秘书（院系管理员）：审核本院系教师的成果、管理本院系教师账号、导出本系汇总报表。
• 校级管理员：管理院系和用户、配置计分规则、汇总全校数据、查看统计报表。
• 系统超级管理员：维护系统参数、管理数据字典、拥有最高权限。

这四类角色构成了系统的权限基础，也是后台菜单和接口权限设计的依据。从业务流来看，主要流程是“教师录入 → 秘书审核 → 系统自动计分 → 各级汇总查看”。教师端提交成果后，成果状态变为待审核；院系秘书登录后可以看到待审核列表，逐条审核通过或驳回；通过的数据进入工作量化算池，系统根据成果类型、级别、作者位次自动计算分值；院系管理员和校级管理员可以按时间段、按人员、按成果类型多维度汇总查询，并导出Excel。

业务闭环里还有一个容易忽略的细节：成果的“年度归属”。科研成果涉及跨年情况，比如一篇论文2024年12月投稿、2025年3月见刊，那应该算哪个年度的工作量？大多数系统按“成果发表/授权/结题日期”归属年度，但配置中一般会留一个手工调整的功能，允许管理员对争议数据调整归属时间。这个细节在答辩时经常被问到，提前想清楚设计逻辑会很加分。

1.3 系统功能模块全景

根据上面分析的业务需求，这个系统的功能模块可以归纳为七个模块，也与项目中的前端页面和后台接口一一对应。

• 用户认证模块：登录、注销、密码修改、验证码、会话管理。
• 用户管理模块：用户列表、新增/编辑/删除、角色分配、院系管理。
• 成果录入模块：论文、专利、课题、获奖、著作等类型的录入与维护。
• 成果审核模块：待审核列表、审核通过/驳回、批量审核、审核记录查询。
• 工作量核算模块：计分规则配置、自动计分、工作量汇总查询。
• 统计报表模块：个人/院系/全校多维度统计、Excel导出、图表展示。
• 系统管理模块：数据字典、公告管理、操作日志。

这七个模块加起来，就是一个完整的中小型前后端分离管理系统。后端对应几十张表和上百个接口，前端对应十几个页面。接下来从技术角度拆解这些模块的实现方式。

2. 技术选型逻辑与项目架构解析

2.1 为什么选SpringBoot而不是SSH或SSM

很多老项目还在用SSH（Spring + Struts + Hibernate）或SSM（Spring + SpringMVC + MyBatis），但这两年做毕设，我强烈建议选SpringBoot。原因很简单：SpringBoot把以前繁琐的配置工作大幅简化了。

SSM项目需要手动配置web.xml、Spring配置文件、SpringMVC配置文件、MyBatis映射文件，一个项目光配置文件就十几个，而且版本兼容稍有偏差就运行不起来。SpringBoot基于“约定大于配置”的思想，内嵌Tomcat服务器，主启动类一运行，Spring容器、自动配置、Web环境全部就绪。原来SSM里天书一样的XML配置，SpringBoot里大多是依赖和注解就能搞定。

这个科研工作量管理系统采用的技术栈是：SpringBoot作为后端基础框架，MyBatis-Plus做ORM和数据操作，MySQL 8.x做数据存储，Redis（或内存缓存）辅助验证码和Token管理，Spring Security或JWT做认证授权。文件存储方面用本地存储路径或MinIO对象存储，Excel导出用Apache POI。这套组合也是当前Java Web开发的主流标准组合，出去找工作面试也拿得出手。

SpringBoot的自动装配原理值得一提。主类上的@SpringBootApplication由@EnableAutoConfiguration驱动，SpringFactoriesLoader会扫描META-INF/spring.factories文件中的自动配置类，按条件注解（@ConditionalOnClass、@ConditionalOnMissingBean等）决定哪些配置生效。比如引入了spring-boot-starter-web，WebMvcAutoConfiguration就会生效，自动配置DispatcherServlet和默认配置；引入了MyBatis-Plus的starter，MybatisPlusAutoConfiguration就会创建SqlSessionFactory。理解这个机制，对排查启动报错特别有帮助。

2.2 为什么前端选Vue

前端的核心诉求是快速开发、组件化复用、易维护。Vue在这三点上都有突出优势。相比传统JSP+JSTL的服务端渲染，Vue天然支持前后端分离开发，前端工程和后端工程可以完全独立，前端用Mock数据并行开发，联调时再切换到真实接口，效率高得多。

Vue的响应式数据绑定机制也是一个核心优势。Vue 3基于Proxy实现响应式，数据变化自动更新视图，不用手动操作DOM。在科研工作量管理系统的成果录入页面，表单字段会根据成果类型动态变化——选了“论文”显示期刊名和卷期页码，选了“专利”显示专利号和授权日期，这种动态表单用Vue的条件渲染和响应式数据实现非常顺手。如果换成jQuery手写DOM事件绑定，代码量大且维护困难。

配合Element UI等组件库，表格、分页、弹窗、表单校验这些后台管理系统的常见界面组件都能直接使用。Vite或Webpack打包后的静态文件可以放在Nginx中部署，也可以直接拷贝到SpringBoot的static目录由后端托管，这对毕设答辩演示环境尤其友好。Vue还提供了一个渐进式学习路径，先看官方文档的“快速上手”样例，再对照项目源码中的router和store，很快就能理解整套前端工程的组织方式。

2.3 项目目录结构与源码阅读指南

拿到源码后第一件事不是打开IDE直接跑，而是先梳理目录结构。后端项目的典型结构如下。

src/main/java/com/example/researchworkload │ ResearchWorkloadApplication.java // 启动类 │ ├── config/ // 配置类：跨域、拦截器、MyBatis-Plus分页插件 ├── controller/ // 控制层：接收请求、返回结果 ├── service/ // 业务层：核心业务逻辑 │ └── impl/ ├── mapper/ // 数据访问层：接口定义 ├── entity/ // 实体类：对应数据库表 ├── dto/ // 数据传输对象：接收前端参数 ├── vo/ // 视图对象：返回前端数据 ├── common/ // 通用类：统一返回结果、异常处理、常量 ├── utils/ // 工具类：JWT工具、Excel工具、文件工具 ├── security/ // 安全相关：登录过滤器、权限处理 ├── aspect/ // 切面：操作日志、权限校验 src/main/resources ├── mapper/ // MyBatis XML映射文件 ├── application.yml // 配置文件：数据库、Redis、文件路径 └── sql/ // 数据库初始化脚本

这个结构是标准的controller → service → mapper三层架构。controller层只负责接收参数和返回结果，不写业务逻辑；service层处理核心业务，比如成果审核的状态流转、工作量计分规则的套用；mapper层通过MyBatis-Plus的BaseMapper接口实现基本CRUD，复杂SQL写在XML文件里。看代码时按“请求路径 → Controller方法 → Service方法 → Mapper方法”这条链路往下追，逻辑非常清晰。

前端Vue项目的结构如下。

src ├── api/ // 接口请求封装，按模块拆分 ├── assets/ // 静态资源、全局样式 ├── components/ // 公共组件：分页、上传、弹窗 ├── layout/ // 整体布局：侧边栏、头部导航 ├── router/ // 路由配置：路径与页面映射、路由守卫 ├── store/ // 全局状态（Pinia或Vuex） ├── views/ // 页面视图：按功能模块组织 │ ├── login/ │ ├── dashboard/ │ ├── achievement/ │ ├── review/ │ ├── workload/ │ └── system/ ├── utils/ // 工具：请求封装、鉴权处理 └── App.vue // 根组件

看前端代码建议从router/index.js开始，先了解有哪些路由、哪些页面、哪些是需要登录权限的，然后对照api/目录中的接口定义，再到views/里看具体页面实现。这样一轮下来，整个系统的脉络就清楚了。

3. 关键模块实现拆解

3.1 认证授权：JWT令牌与登录流程

大多数这类系统的登录认证采用JWT（JSON Web Token）方案。原理不复杂：用户登录成功后，后端生成一个包含用户ID、用户名、角色信息的令牌返回给前端；前端把令牌存储在本地（localStorage或Pinia）；后续每次请求在请求头中携带Authorization: Bearer <token>；后端通过拦截器或过滤器校验令牌合法性，解析出用户信息，再配合@PreAuthorize注解进行角色权限校验。

登录接口的典型实现逻辑如下。

@PostMapping("/login") public Result<?> login(@RequestBody LoginDTO loginDTO) { // 1. 校验验证码（如果配置了） String code = redisUtils.get(loginDTO.getUuid()); if (code == null || !code.equalsIgnoreCase(loginDTO.getCode())) { return Result.error("验证码错误"); } // 2. 查询用户并校验密码（BCrypt加密比对） User user = userService.getUserByUsername(loginDTO.getUsername()); if (user == null || !BCrypt.checkpw(loginDTO.getPassword(), user.getPassword())) { return Result.error("用户名或密码错误"); } // 3. 校验用户状态 if (user.getStatus() == 0) { return Result.error("账号已被禁用"); } // 4. 生成JWT令牌 String token = JwtUtils.createToken(user); // 5. 返回用户信息和令牌 return Result.success(new LoginVO(token, user)); }

这段代码是很多SpringBoot项目的标准登录模板，重点有三处。一是密码存储必须加密，项目中一般用BCrypt，同一个密码每次哈希结果都不同，防止彩虹表攻击。二是验证码存在Redis并设置过期时间，防止验证码复用。三是JWT令牌设置合理的过期时间，系统管理类项目一般设2到12小时，过长有安全风险，过短影响使用体验。

前端配合路由守卫实现访问控制。Vue Router的beforeEach钩子里判断meta.requiresAuth字段，如果路由需要登录而本地没有Token，就跳转到登录页；有Token则正常放行。角色权限对应的菜单通常由后端返回，前端根据角色类型动态渲染侧边栏菜单，这个设计也符合RBAC（基于角色的访问控制）模型。

3.2 成果录入与多态数据表设计

科研工作量管理系统中最有设计含量的部分是“成果”这一实体的数据建模。论文、专利、课题、获奖、著作，共同点是都属于成果，但各自的字段根本不同。论文有期刊名、ISSN号、卷期页码、收录情况；专利有专利号、专利类型、授权公告日；课题有课题来源、立项编号、经费金额、结题日期；获奖有奖励级别、授奖单位、获奖等级。如果设计成一张大宽表，几十个字段大部分是空的，冗余严重，扩展新成果类型还要改表结构。

常见的解决方案是“主表 + 扩展表”或“主表 + 类型字段 + JSON存储”。我见过这个项目的前端动态表单后，猜测其后端采用的是主表加类型表设计。

成果主表（achievement）字段大致包括：

id, user_id, type(论文/专利/课题/获奖/著作), title, status(待审核/通过/驳回), apply_date, audit_by, audit_time, audit_comment, score, year, create_time, update_time

每种成果类型对应一张从表。以论文为例：

论文扩展表：id, achievement_id, journal_name, issn, volume, issue, pages, include_type(SCI/EI/核心/普刊), author_count, author_position, is_corresponding

查询时主表和从表通过achievement_id关联，按类型分别查询。这样既避免了字段冗余，扩展新成果类型时只需新增一张扩展表，对已有代码无侵入。前端在录入页面对应动态表单，后端在service层根据type字段分发到不同的保存逻辑。

成果录入模块还有一个值得注意的细节：作者位次与是否通讯作者直接影响计分权重。同一篇论文，第一作者和工作量全分，第二作者可能只算三分之一。因此在录入表单中必须有“作者位次”、“作者总数”、“是否通讯作者”三个字段，后端计算工作量时按规则套用。

3.3 工作量自动核算：计分规则与实现策略

工作量核算是这个系统的算法核心。计分规则因学校而异，常见规则举例如下。

• 论文：SCI一区30分、二区20分、三区15分、四区10分；EI论文8分；北大核心5分；一般期刊2分。
• 专利：发明专利授权10分、实用新型5分、外观设计2分。
• 课题：国家级结题50分、省部级结题30分、厅局级结题15分。
• 获奖：国家级一等奖50分、二等奖40分、三等奖30分；省部级相应减半。

自动计分的设计思路是把这些规则做进规则表，而不是硬编码在Java代码里。原因很简单：规则会变，学校每年的计分文件可能调整某项分值，硬编码意味着改代码、重新打包、重新部署，代价太高。

规则表（score_rule）的核心字段：

id, type(成果类型), level(成果级别), score(基础分值), author_position_weight(作者位次权重), calculate_type(计分方式), status(启用/停用), remark, create_time, update_time

工作量计算的核心方法逻辑类似这样。

public BigDecimal calculateScore(Achievement achievement) { // 1. 根据成果类型和级别查询基础分值 ScoreRule rule = scoreRuleMapper.findByTypeAndLevel( achievement.getType(), achievement.getLevel()); if (rule == null) return BigDecimal.ZERO; BigDecimal score = rule.getScore(); // 2. 根据作者位次套用权重 BigDecimal weight = rule.getAuthorPositionWeight(achievement.getAuthorPosition()); score = score.multiply(weight); // 3. 特殊情况规则：通讯作者加成、项目经费加成等 if (achievement.getIsCorresponding() && rule.getCorrespondingBonus() != null) { score = score.add(rule.getCorrespondingBonus()); } return score.setScale(2, RoundingMode.HALF_UP); }

规则表设计让毕设答辩时可以理直气壮地说“这个系统的计分规则是支持动态配置的”，这是工作量模块的加分项。

3.4 Excel导出与文件上传

科研工作量管理系统离不开报表导出功能，期末汇总时科研秘书要按院系导出Excel发给人事处。导出用Apache POI操作Workbook对象，逻辑不复杂但细节多。核心步骤是先创建XSSFWorkbook和Sheet，然后写入标题行和数据行，设置单元格样式（边框、字体、列宽），最后通过HttpServletResponse设置响应头让浏览器下载。下载时需要注意文件名编码，否则中文文件名在浏览器里会乱码。常见写法是：

String fileName = URLEncoder.encode("工作量汇总表.xlsx", "UTF-8"); response.setHeader("Content-Disposition", "attachment;filename=" + fileName);

文件上传主要用于老师上传论文PDF、专利证书扫描件等证明材料，与成果记录关联。存储策略上，小项目直接存本地磁盘路径（upload/目录），数据库存相对路径，简单可靠。查询时通过一个文件访问接口返回流。如果素材量大，会引入对象存储（MinIO或阿里云OSS），但毕设规模用本地文件够了。上传组件前端用Element UI的el-upload，设置action指向后端接口，后端将文件保存在指定目录，返回文件路径作为表单字段值一并提交。

4. SQL脚本与接口文档的实战使用

4.1 SQL脚本的正确导入姿势

下载的压缩包解压后，在sql/目录下通常会看到类似research_workload.sql的脚本文件。拿到手先不要急着双击导入，先打开文件看几个内容。

先看开头的注释和建库语句。有的脚本自带CREATE DATABASE语句，有的没有；有的默认库名是research_workload，有的是workload_db，这些信息直接影响后续连接配置。再浏览一下表数量，主要看有没有初始数据。很多毕设项目的SQL脚本会内置一个管理员账号（比如admin/admin123），这个初始账号是登录系统的钥匙，绝不能丢。看脚本的方式是用编辑器打开，搜INSERT INTO看有哪些表有初始数据。

导入操作推荐用Navicat或MySQL Workbench。用Navicat时新建数据库，字符集选utf8mb4（因为utf8存不了生僻字和部分特殊符号），排序规则选utf8mb4_general_ci，然后右键运行SQL文件，选择脚本路径。如果脚本里没有CREATE DATABASE，需要手动创建库再运行脚本；如果脚本最前面有USE xxx语句，就保证创建的库名一致。

导入成功后重点检查三张表：用户表里有没有预置账号、角色表有没有数据、用户角色关联表是否关联正确。我遇到过不止一次脚本导入后登录报“用户不存在”，排查结果是用户角色关联表里没有插入关联记录，前端拿到了Token但接口鉴权失败。

4.2 接口文档阅读方法论

接口文档是前后端联调的契约。这个项目的接口文档一般不单独做成独立在线系统，而是以Swagger注解生成在线API页面，或者配合Markdown接口文档文件供下载后查阅。

Swagger启用的方式很简单，在pom.xml引入springfox或springdoc-openapi依赖，在配置类上添加@EnableOpenApi注解，启动项目后访问http://localhost:8080/swagger-ui/index.html或/doc.html即可看到所有接口。接口按模块展示，每个接口包含请求方法、路径、请求参数、响应示例。看接口文档时先看每个Controller类的@Api(tags = "用户管理")描述，理解这个模块有哪些功能，然后逐条看接口定义。

看接口文档的实操技巧是按照业务链路来读，而不是按Controller顺序读。建议先看登录接口的请求参数结构和返回数据结构，再看成果保存接口。以登录为例，先看请求体需要哪些字段（username、password、code），再看返回体里data.token字段，这个字段就是前端要存的令牌。对每个接口，重点看三处：请求参数是否必填、参数类型是form-data还是JSON、成功响应的code是多少（有的项目成功是200，有的成功是1或0）。

4.3 从接口文档反推前端接法

接口文档不只是给后端看的，前端拿到接口文档后要做的第一件事是封装请求基础层。一个典型的axios封装会配置baseURL，添加请求拦截器从localStorage取Token并放入请求头，添加响应拦截器统一处理code不是成功值时弹出错误提示。

// 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 }) 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 || '请求失败') if (res.code === 401) { router.push('/login') } return Promise.reject(new Error(res.message)) } return res }, error => { ElMessage.error(error.message || '网络错误') return Promise.reject(error) } )

这个封装是所有前端页面的基础依赖。每个功能模块的API请求（如src/api/achievement.js）统一用request实例发出，后端接口路径、请求参数、返回结构就自然映射到前端代码里。实际联调中只要后端接口路径和前端api目录下的定义保持一致，页面就能跑通。

5. 本地环境搭建与完整启动实操

5.1 后端启动的详细步骤

拿到源码启动后端，需要准备的工具清单：JDK 8或11（查看pom.xml里的java.version）、Maven 3.6+、IntelliJ IDEA、MySQL 8.x、Redis（如果项目用了）。版本对应关系很关键，JDK版本和SpringBoot版本不匹配是启动报错的第一大原因。

用IDEA打开后端项目文件夹后，等待Maven依赖下载完成。依赖下载慢或失败时，检查Maven的settings.xml是否配置了阿里云镜像，这是国内开发的标准操作。

后端启动前的关键操作是修改application.yml里的配置项，重点检查数据库连接：

spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/research_workload?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai username: root password: yourpassword redis: host: localhost port: 6379

如果启动时控制台报“Access denied for user 'root'”，说明密码配错；报“Unknown database”，说明research_workload库没建或库名不对；报“Communications link failure”，先看MySQL服务有没有启动。这些现象是后端启动排查中最常见的三类。另外，Redis不是所有毕设都用，但如果项目引入了Redis依赖而没有启动Redis服务，应用启动时连接失败直接报错。如果不用Redis，需要把涉及Redis的配置和依赖移除，或应用spring-boot-starter-data-redis的lettuce配置做connect-timeout短期容错处理。

5.2 前端启动的详细步骤

前端工程通常在单独文件夹中，比如frontend/或vue-web/。首先确认本机安装Node.js，推荐使用Node 16到18之间的长期支持版本。Vue 3项目要求Node版本不能太老，命令行执行node -v确认版本。然后安装依赖：

npm install -g @vue/cli cd frontend npm install npm run dev

npm install时常见问题是依赖源太慢或报node-sass安装失败。推荐先把npm源换成淘宝镜像：npm config set registry https://registry.npmmirror.com。node-sass失败则查看package.json里是否用了旧版sass依赖，考虑换成sass或dart-sass。

启动成功后命令行会提示本地访问地址，通常是http://localhost:5173（Vite启动）或http://localhost:8080（Vue CLI启动）。浏览器打开后如果出现页面但接口请求报404或跨域错误，就是前后端联调配置的问题。开发环境常用方案是在前端工程根目录的vue.config.js（Vue CLI）或vite.config.js（Vite）里配置代理：

// vite.config.js server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这样前端请求/api/login会被转发到后端http://localhost:8080/api/login，绕开跨域问题。生产部署时则用Nginx统一代理前端静态资源和后端接口。

5.3 常见启动报错与问题排查表

把实际操作中最常遇到的启动问题整理成速查表，遇到直接对照处理。

后端问题排查表：

前端问题排查表：

还有一个新手容易踩的问题：后端跑起来了，但访问的是localhost:8080，前端页面配的接口地址是localhost:8081，两边端口对不上，接口必然失败。遇到联调问题，先确认浏览器开发者工具里Network面板的请求URL到底发到了哪里。

6. 项目二次开发与毕设答辩的加分建议

6.1 想改造题目，从哪里下手

很多同学拿到的毕设题目不会和这个系统完全一致，但万变不离其宗。比如题目改成“基于SpringBoot+Vue的高校教师科研管理系统”，只需要在成果录入基础上增加教师基本信息管理、年度考核模块；改成“实验项目管理系统”，把成果主表替换成实验项目主表，扩展表替换成实验设备、实验耗材表，计分规则换成经费结算规则，整个框架完全可以复用。框架最值钱的部分——用户角色权限、前后端分离、审核流、自动算分、报表导出——这些模板直接继承，业务表按题目换一换即可。

建议改造优先级排序：

• 替换业务实体字段（把“论文”改成题目指定的核心对象）
• 增加1-2个新功能模块（如图表统计ECharts展示）
• 调整计分规则或审核流程（如增加多级审核）
• 修改数据库初始数据（如院系名称、管理员账号）

6.2 答辩时怎么讲清楚这个系统

答辩时间通常只有5到10分钟，讲系统不要从头到尾念PPT，而是按“痛点→方案→亮点→演示”的逻辑展开。先说清楚为什么需要科研工作量管理系统，用三个痛点开头；然后说系统分层架构，画出清晰的技术架构图；接着讲核心模块时强调“计分规则可配置”和“RBAC权限控制”这两个技术亮点；最后现场演示登录、录成果、审核、查报表这条主链路，演示时提前准备一条成果数据，现场录入时间不够会很尴尬。

容易被追问的问题要提前准备。比如“JWT和Session有什么区别”、“如果用户Token泄露怎么办”、“计分规则修改后历史数据是否重新计算”、“数据量大了怎么优化查询”。最后一个问题可以从分页查询、索引优化、缓存三个方面回答，展示思考深度。

6.3 实操后的个人经验总结

拿到这类完整项目源码，正确的打开方式不是急着跑起来，而是先“考古”文件。我建议按以下顺序学习：先读README和数据库设计文档，再导入SQL脚本看表结构，然后启动后端用Swagger看一遍所有接口，最后启动前端点一遍页面。这样过了两轮后，系统的全貌就立体了。直接上手改代码，容易迷失在细节里。

数据库连接配置是运行项目最大的一道坎，我反复强调这三项：MySQL账号密码、库名和SQL脚本里的USE语句是否一致、MySQL服务有没有启动。把这三点检查清楚，后端启动成功率能到九成。前端则是依赖安装和node版本，务必先看package.json里要求的依赖版本，Vue 2项目用Node 14、Vue 3项目用Node 16以上，版本不对装依赖必出幺蛾子。

还有一个小技巧。下载的源码里如果有README.md一定要先读，很多前人踩坑的提示都写在里面。比如某项需要修改的文件、某个路径中不能有中文、MySQL需要用特定版本等。这些小提示价值千金，我见过有人就因为项目路径带中文导致Python脚本执行失败，折腾半天才发现是这种低级问题。

最后说一句，SpringBoot+Vue这个组合在Java Web毕设里已经是最成熟的方案，但成熟不等于简单。真正把一个项目从源码变成自己能讲清楚、能改得动、能顺利跑完答辩的成果，靠的是动手走通一遍完整流程。这篇把从这个项目的业务到技术再到环境部署的关键环节都拆开了，照着动手操作一遍，比你抱着代码看十遍都管用。