1. 这个项目到底解决什么问题科研工作量管理的真实痛点1.1 科研工作量的场景长什么样先说说我做这个系统时的实际背景。高校或科研院所的科研管理绕不开一个非常琐碎但又必须严肃对待的环节科研工作量核算。老师发表了一篇论文、申请了一项专利、承接了一个横向项目、指导学生拿了竞赛奖项这些成果都需要折算成工作量和绩效、评优、职称评审直接挂钩。过去很多单位的做法是年底发一张Excel表让老师自己填然后科研秘书人工核对。听上去不难实际跑起来全是问题填表格式五花八门有人把论文级别写错有人漏填但后期又要补审核材料纸质版和电子版对不上统计口径不同部门还不一样。最头疼的是年底汇总时几十个老师的几百条记录全靠人工去数效率和准确率都可想而知。所以科研工作量管理系统这个名字听起来朴素本质上是把一套申报—审核—统计—反馈的闭环流程搬到线上。用户提交个人成果审核人按规则核验系统自动汇总数据管理员可以按部门、按类型、按时间段出统计报表。这就是我当初选这个课题的直接原因它不是一个假大空的玩具项目而是每个高校实际都在用的真实业务系统拿来当毕设、课设既有价值又不至于复杂到做不完。1.2 为什么它适合做毕设和课程设计我给准备选这个课题的同学一个建议科研工作量管理系统是恰到好处的选题。先说复杂度——它比简单的新增删改查项目比如图书管理、学生信息管理多了一个审核流程和统计报表能体现出业务逻辑设计的能力但又不至于像电商系统那样涉及订单状态机、支付回调、分布式事务等一大堆让人劝退的边界问题。再说技术覆盖面。前端Vue需要处理动态表格、多表单校验、图表展示后端SpringBoot要处理认证授权、文件上传、复杂查询、事务控制数据库要设计多表关联和统计聚合。这三个维度刚好能覆盖面试官和答辩老师最常考察的知识点也够你在简历上写出一段有含金量的项目经历。更重要的是这个项目的需求是自解释的。答辩时老师说你为什么做角色区分你不需要解释什么叫RBAC直接说因为申报人不能审核自己的工作审核人需要看到待办清单管理员需要全局统计这就够了。业务逻辑和技术实现能挂上钩是毕设拿高分的核心。2. 技术选型的前因后果SpringBoot、Vue、MySQL为什么是黄金组合2.1 后端为什么选SpringBoot这个话题我知道很多人答辩前才临时背答案所以我多说几句。选SpringBoot不是因为它火而是因为它帮你解决了Java后端开发里最常见的工程化问题。传统SSM的痛点大家都听过配置太啰嗦。数据源、事务管理器、MyBatis的SqlSessionFactory、SpringMVC的视图解析器每一个都要写一堆XML然后Tomcat里还要配置应用上下文。这些配置对初学者来说任何一个地方写错都跑不起来而且报错还看不懂。SpringBoot的核心思路是约定优于配置——默认把常用配置内置好你只需要在application.yml里覆盖自己需要改的部分。这里分享一个我实际项目的启动类代码很多毕设项目都是从这里开始的SpringBootApplication MapperScan(com.example.research.mapper) public class ResearchWorkloadApplication { public static void main(String[] args) { SpringApplication.run(ResearchWorkloadApplication.class, args); } }MapperScan是很多人容易漏掉的关键点。如果你用了MyBatis或MyBatis-Plus这行注释不加上启动时Spring容器会找不到Mapper接口报一堆Property sqlSessionFactory or sqlSessionTemplate are required之类的错。这也是每个SpringBoot项目第一个坑。2.2 前端为什么选Vue前端这块市面上有React、Vue、Angular三选一的问题。做毕设和中小型管理后台Vue是我最推荐的原因很实在学习曲线平缓中文生态好配套组件库最省心。Vue的核心概念其实就三个响应式数据、指令、组件化。做管理后台你不需要写复杂的状态管理也不需要理解虚拟DOM的diff算法细节你只需要掌握v-model做表单绑定、v-for渲染列表、Vue Router切换页面、axios调接口就能做出一个完整的前端。这里说一下Vue 2和Vue 3的选择。如果是今年的毕设建议直接上Vue 3 Element Plus Vite不要再用Vue 2了。原因很直白Vite启动项目只要几秒钟Webpack要几十秒答辩现场演示时前端长时间转圈会非常尴尬。而且Element Plus从组件风格到TypeScript支持都比Element UI好。下面是Vue 3项目用Vite创建的标准命令npm create vitelatest research-web -- --template vue cd research-web npm install npm run dev注意npm create vitelatest的latest是有讲究的不然你可能会拉到旧版本的初始化模板。创建完以后可以先跑一遍默认页能出来再装Element Plus。2.3 MySQL为什么不需要纠结版本数据库这块MySQL基本是毕设的标准答案。不要碰Oracle太重了也不要碰SQLite虽然轻量但你的答辩PPT上关于数据库设计的内容会很单薄。我的建议是MySQL 5.7或8.0都行。如果你在Windows上本地开发安装MySQL 8.0后记得一个坑mysql_native_password插件的问题。很多教程会带你创建用户但你直接用了8.0默认的caching_sha2_password密码验证然后Java侧连接的驱动版本过低就会报Authentication plugin caching_sha2_password cannot be loaded。解决办法要么把MySQL 8.0的驱动版本升到8.0.x要么在创建用户时显式指定CREATE USER workloadlocalhost IDENTIFIED WITH mysql_native_password BY Workload123; GRANT ALL PRIVILEGES ON workload_db.* TO workloadlocalhost; FLUSH PRIVILEGES;如果用的是MyBatis-Plus在application.yml里还有一处高频失误驱动类名写错。新版MySQL驱动类名是com.mysql.cj.jdbc.Driver老版本是com.mysql.jdbc.Driver。而且新版连接后会在控制台上冒出一条Loading class com.mysql.jdbc.Driver的警告虽然不影响运行但答辩时被问到就别扭。3. 数据库设计十几张表是怎么拆出来的3.1 先从业务角色梳理实体关系拿到需求别急着建表。我一般先用一句话概括系统里的核心角色做什么然后以此推导需要哪些表。这个系统的角色基本是三个系统管理员、教师科研人员、审核人可以是科研处的人员。可以总结为教师登录后台报工作量申请维护个人资料查看自己的审核结果。审核人查看待审核申请核对材料通过或驳回。管理员管理用户和角色管理工作量类型查看统计报表。所以我需要一张用户表、一张角色表、一张用户角色关联表。工作量本身是一张主表但工作量的类型论文、专利、纵向项目、横向项目、获奖、学术会议等必须单独建表。为什么因为每个类型对应不同的工作量计算规则和不同的需要填写的字段。如果直接写在申请表的字段里后续加类型就要改表结构这是管理者最不想看到的事情。3.2 核心表结构设计细节下面是我推荐的八张核心表答辩老师最喜欢围绕这些表问问题。表名作用关键字段t_user用户表id, username, password, real_name, department_id, email, phone, statust_role角色表id, role_name, role_codet_user_role用户角色关联表id, user_id, role_idt_workload_type工作量类型表id, type_name, type_code, unit_score, statust_workload_claim工作量申报主表id, user_id, type_id, claim_title, claim_date, score, file_url, status, audit_remark, create_timet_audit_record审核记录表id, claim_id, auditor_id, audit_result, audit_opinion, audit_timet_department部门表id, dept_name, parent_idt_announcement公告表id, title, content, publisher_id, publish_time这里有两个容易忽略的设计点。第一t_audit_record和t_workload_claim的审核状态是并存的。很多同学只在主表里留一个status字段申请被驳回改一改再提交原来的审核记录就没了。审核记录单独建表是为了保留每次审批的痕迹方便最终对账。这个设计在答辩时非常加分因为它体现出了你对业务追溯的需求理解。第二工作量的类型表里要放一个unit_score单位分值字段。比如一篇SCI论文算5分一篇中文核心算3分一个发明专利折算10分。这些计分规则是会变的每年政策都可能调整所以不能写死在代码里而是让管理员在后台维护类型表。系统在计算教师总工作量时从这个表读取分值乘以数量即可。这也是我在实际开发中比较满意的一处设计。3.3 工作量得分怎么算工作量得分这部分我建议你在设计表结构的同时就把计算逻辑理清楚。这里给一个简化版的规则供参考论文类按论文级别SCI、EI、中文核心、普刊对应不同分值一张表里可以加一个paper_level字段。专利类按专利类型发明专利、实用新型、软著对应不同分值。项目类按项目来源国家级、省部级、横向和到账经费综合计算。这个最复杂因为可能涉及项目组成员的分摊比例我给毕设的简化方案是负责人拿全额成员按百分比填。计算逻辑在后端用一个策略模式来实现会显得很有水平。比如定义ScoreCalculator接口每个类型实现一个calculate方法public interface ScoreCalculator { BigDecimal calculate(WorkloadClaim claim); } Component(paperCalculator) public class PaperCalculator implements ScoreCalculator { Override public BigDecimal calculate(WorkloadClaim claim) { WorkloadType type claim.getWorkloadType(); BigDecimal baseScore type.getUnitScore(); if (SCI.equals(claim.getPaperLevel())) { return baseScore.multiply(new BigDecimal(2)); } return baseScore; } }代码里用Component(paperCalculator)给每个策略一个bean名称然后通过工厂根据类型编码去拿对应的Calculator。这个实现并不复杂但比写一堆if-else要优雅答辩时可以说这里用了策略模式应对不同工作量类型的计算差异这是技术评审老师很愿意听的亮点。4. 后端核心实现登录认证到申报审核的完整链路4.1 JWT登录认证的落地方式科研工作量管理系统是有角色权限之分的所以登录认证是第一道门槛。现在主流方案是JWT Spring Security但也有人用Shiro。我的建议是如果只求稳Spring Security JWT完全够用如果不想写那么多Security的配置类也可以直接用Sa-Token或自研一个拦截器。这里我必须说一句大实话很多毕设项目用Spring Security其实是杀鸡用牛刀而且它的过滤器链非常难配置一个细节不对就是全盘401或者放行全部接口排查起来很费时间。我自己在这个项目里就换成了更直观的方案后端用拦截器HandlerInterceptor验证JWT把用户信息放进ThreadLocal遇到需要管理员权限的接口再单独校验角色。核心思路是这样的用户登录成功后后端签发一个JWT里面带上userId和roleCode前端存到localStorage。后端写一个AuthInterceptor拦截除登录接口外的所有请求解析请求头里的Authorization验证签名和过期时间然后把解析出来的用户信息塞进UserContext业务代码里随时能拿。public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (StringUtils.isBlank(token)) { throw new BizException(401, 未登录); } Claims claims JwtUtil.parseToken(token.replace(Bearer , )); UserContext.set(claims); return true; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { UserContext.clear(); } }重点注意afterCompletion里的UserContext.clear()。不清理会导致线程池复用线程时下一个请求拿到上一个请求的用户信息这在正式环境是严重的数据越权漏洞。把这个细节写进毕设说明书里比写十页项目背景有分量得多。密码存储也不要用明文直接一个表单加密加一个数据库加密前端先用SHA-256做一次摘要后端再拼接盐值做BCrypt加密。有人说前端加密没必要我承认理论上是HTTPS负责传输安全但毕设没有HTTPS加点盐算是一层防御起码论文里能写采用了前端摘要加后端加盐哈希双重防护。4.2 申报流程的状态机设计工作量申报核心流程可以理解为一条状态链待审核 → 审核通过 / 审核驳回。为了让系统更好用我建议加一个已撤回状态教师提交后如果发现填错了在审核人还没有处理时可以撤回修改这样可以减少无效审核件。状态流转如果用if-else实现最怕的是后面加状态时逻辑混乱。我推荐用一个简单的状态机枚举public enum ClaimStatus { PENDING(0, 待审核), APPROVED(1, 已通过), REJECTED(2, 已驳回), WITHDRAWN(3, 已撤回); private final int code; private final String desc; }审核接口里先判断原状态是否允许变更。比如已通过或已驳回的不允许再进入待审核已撤回的只能编辑后重新提交不能重复审核。这些约束在Service层写清楚再配合数据库里一个version字段做乐观锁防止多人同时操作同一条申报记录。乐观锁的实现很简单更新时WHERE id ? AND version ?更新成功则version 1如果影响行数为0说明有并发冲突。虽然这个系统并发压力不大但这是一个容易讲清楚的技术点。4.3 文件上传功能的两个坑科研工作量申报必然要传附件比如论文首页、专利证书扫描件。文件上传这个功能写起来简单踩坑却不少。第一个坑是后端接收MultipartFile时Spring Boot默认单文件大小只有1MB。教师传一个PDF可能轻松超过这个数前端上传到一半报错让你误以为是前端的问题。解决方法是在application.yml里调大限制spring: servlet: multipart: max-file-size: 20MB max-request-size: 50MB第二个坑是文件存储路径。不要用System.getProperty(user.dir)拼接一个绝对路径因为打包成Jar后启动目录可能和部署目录不一致。我的做法是配置一个基础路径属性比如file.upload-dir: ./upload/然后用Paths.get(uploadDir).toAbsolutePath().normalize()处理。同时文件名不能直接用用户上传的原始文件名要UUID重命名防止出现中文乱码和路径穿越问题。4.4 月度年度统计的SQL写法统计报表是系统给管理员看的核心功能。比如要统计2024年3月各院系的申报数量你当然可以在Java里把所有数据查出来再用Stream去groupBy但数据量大了以后这么做既笨又慢。直接在SQL里用聚合函数更清爽select idselectMonthlySummary resultTypemap SELECT d.dept_name, COUNT(c.id) AS claim_count, COALESCE(SUM(c.score), 0) AS total_score FROM t_workload_claim c JOIN t_user u ON c.user_id u.id JOIN t_department d ON u.department_id d.id WHERE c.status 1 AND c.create_time BETWEEN #{startTime} AND #{endTime} GROUP BY d.dept_name ORDER BY total_score DESC /select这里用到了COALESCE(SUM(c.score), 0)它的作用是如果某个部门当月在审核通过状态的工作量记录数为0SUM会返回NULL如果不做处理前端图表会把这个数据当成空值而实际业务上0和没有数据虽然相近但统计意义不同。加COALESCE后返回0前端ECharts渲染时不会断开折线。很多人写这种统计SQL时忘记一个条件只统计已通过审核的工作量。如果把status 1漏掉把待审核和驳回的也算进去管理员会一脸迷惑。所以我在写统计功能的时候习惯先看一眼SQL的执行计划确认索引有没有走到虽然毕设数据量不大走不走索引无所谓但这个习惯值得养成。5. 前端页面搭建Vue组件化设计中的实操思路5.1 路由与权限控制怎么配合后端在Vue项目里路由设计要直接对应登录、首页、工作量申报、我的审核、用户管理、工作量类型管理、报表统计这几个页面。我习惯把路由拆成两个集合constantRoutes不需要登录和dynamicRoutes需要权限其中动态路由的生产逻辑是登录后根据用户角色动态挂载的。不过如果你做毕设时不想搞得太复杂我更推荐一个取巧但效果不错的做法前端只做菜单显隐控制后端做API级权限。也就是说前端把全部路由都注册但根据角色决定侧边栏的菜单显示哪些项后端每个接口都校验角色权限。这样做的好处是前端不会因为动态路由的加载顺序报404代价是懂行的人会说你没做路由级权限。但我亲身感受是毕设项目中后端API鉴权才是真正决定数据安全的防线前端路由守卫只是锦上添花。菜单显隐用Vue的路由守卫配合角色码router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (!token to.path ! /login) { next(/login); return; } if (token) { const roleCode localStorage.getItem(roleCode); if (to.meta.roles !to.meta.roles.includes(roleCode)) { next(/403); return; } } next(); });这里有一个细节如果用户直接在地址栏输入一个没有权限的路径next(/403)会把他导向无权限页面。403页不要做得太简陋做一个简单的提示和返回首页按钮很多评委老师会实际去点一下这算是个体验分。5.2 工作量申报表单的联动和校验工作量申报页面是整个前端交互的重头戏。教师选择工作量类型后表单要显示出不同的字段。比如选了论文就显示期刊名、论文级别、本人角色、发表时间、附件上传选了专利就显示专利名称、专利号、授权时间、专利类型。实现方式很简单在data里放一个extraFormList数组根据当前选中的workloadTypeId动态循环渲染el-form-item v-foritem in extraFormList :keyitem.prop :labelitem.label :propitem.prop el-select v-ifitem.type select v-modelform[item.prop] el-option v-foropt in item.options :keyopt.value :labelopt.label :valueopt.value / /el-select el-input v-else v-modelform[item.prop] / /el-form-item动态表单的校验规则也是一样的套路在rules里按字段名动态添加。我建议把每个工作量类型对应的字段配置成一份JSON放在前端项目的src/config/workloadFormConfig.js里。这样后端不用为每种类型写不同的接口前端也不需要写无数个v-if分支后续扩展新类型只需要改配置文件。这个点我要单独说用配置驱动表单是真正的毕设亮点。大部分毕设项目的前端都是写死的你用了配置化答辩时就可以说新加一种工作量类型无需改前端代码只需在配置文件中声明字段和校验规则。这句话比我能熟练使用ElementUI有价值得多。5.3 axios请求封装里容易忽视的细节前端和后台交互axios的封装几乎是必须的。除了常规的baseURL、超时时间、Authorization请求头注入还要统一处理两种异常token过期和业务错误。我的做法是在响应拦截器里判断后端返回的code如果code 401就清理本地存储并跳转登录页如果code是其他业务错误用Element Plus的ElMessage弹提示。这么做可以在Service层少写大量重复的错误弹出代码。service.interceptors.response.use( (response) { const res response.data; if (res.code 401) { localStorage.clear(); router.push(/login); return Promise.reject(new Error(登录过期)); } if (res.code ! 200) { ElMessage.error(res.msg || 请求失败); return Promise.reject(new Error(res.msg)); } return res; }, (error) { ElMessage.error(error.message || 网络异常); return Promise.reject(error); } );前端还有一个项目前期就要决定的事情mock数据还是真实后端。我的建议是别做mock直接后端起一个接口前端直接请求。很多新手前期写页面时因为后端没用就喜欢用mock但mock数据前前后后写的量也不少而且联调时要全部推翻属于两头吃亏。正确做法是后端先把用户登录、工作量类型列表这些基础接口搞定前端同时开工哪怕数据是空的接口通了就是通了。6. 本地跑通与部署避坑我能想到的每一个坑都有解决方案6.1 环境版本组合推荐我推荐一套我自己用着很稳的版本组合照着配基本不会出大问题组件版本说明JDK1.8 或 11毕设用JDK8最稳Spring Boot 2.7兼容性最好Spring Boot2.7.x不要直接上Spring Boot 3除非你愿意面对Jakarta包名迁移问题MySQL5.7 或 8.08.0要配对应驱动版本5.7省心Node.js16.x 或 18.xVite 4要求Node 16Vue3.x配Element PlusMyBatis-Plus3.5.x代码生成器能省很多事这里要特别强调Spring Boot 3的问题。Spring Boot 3要求的Java版本最低是17javax.*包迁移成了jakarta.*JWT库也有一部分不兼容。热搜词里有springboot版本太高这样的说法说明很多人踩了这个坑。我的观点很明确既然是毕设没必要追逐最新版本稳定压倒一切。Spring Boot 2.7照样有大量生产环境在用技术评审看的是设计思路不是版本号。6.2 前后端联调时的高频问题跨域本地开发时前端在http://localhost:5173后端在http://localhost:8080。浏览器同源策略会直接拦截这就是跨域问题。有人说加个后端配置CrossOrigin注解搞定但我不建议用这个。你在几百个接口上一个个加不现实直接在Spring Boot里写一个WebMvcConfigurer的跨域配置最省事Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }注意allowedOriginPatterns(*)和allowedOrigins(*)的区别当allowCredentials(true)允许携带Cookie时allowedOrigins(*)会被浏览器拒绝必须用Patterns。虽然JWT方案一般不依赖Cookie但万一答辩时你突发奇想说要接Session这个配置就能兜住。前端这边开发环境的代理也能解决跨域。在vite.config.js里这样配server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }这样前端请求/api/user/login会代理到后端的http://localhost:8080/api/user/login浏览器里看是没有跨域的。两种方式选一个即可建议后端配置为主前端代理为辅双保险。6.3 打包部署jar包里的静态资源处理毕设需要演示最让人放心的方式是打包成一个可执行Jar再把前端的dist目录放进后端的static目录里这样只需要启动一个进程不用解释为什么还要单独启动一个前端服务。具体做法是前端执行npm run build生成dist把dist目录里的index.html和assets文件夹复制到后端src/main/resources/static下然后重新打包后端mvn clean package -DskipTests java -jar target/research-workload-0.0.1-SNAPSHOT.jar这样浏览器访问http://localhost:8080就能直接进系统。如果是在服务器上部署记得给Linux服务器装好JDK和MySQLMySQL的数据初始化直接用建库SQL脚本加INSERT语句。热搜词里有rpm安装mysql、linux安装mysql这类我建议你提前在服务器上把MySQL 5.7装好连接工具用Navicat或者MySQL Workbench都行。部署时最容易出丑的一个地方是Tomcat端口冲突。如果你服务器上已经有一个进程占了8080一个简单的办法是改端口server: port: 8088还有一个坑是防火墙。云服务器默认开了防火墙安全组策略没放行8088端口你在浏览器里就会一直等待连接。这个不属于代码问题但每年都能让一堆人折腾半天。收到部署环境后先把firewall-cmd --list-ports看一下或者直接把安全组入方向规则放开对应端口。7. 答辩准备与代码之外的加分项7.1 答辩时最容易被追问的五个技术点结合多年观察科研工作量管理系统答辩时被问的问题高度集中在这几个地方你是怎么实现权限控制的回答要点登录签发JWT拦截器解析token解析出角色编码后端在需要鉴权的RequiresRole(ADMIN)注解里做角色匹配前端用路由守卫配合菜单显隐形成双重控制。工作量分数是怎么计算的回答要点分数规则存在t_workload_type表的unit_score字段不同类型使用不同的计分策略策略类实现了同一个ScoreCalculator接口通过工厂按类型获取所以新增工作量类型不用改核心逻辑。数据库为什么这么设计用审核记录表举例。因为审核过程需要留痕不能只靠主表一个状态字段。老师驳回之后的历史审批意见要能追溯所以把审核记录拆成独立表和主表是多对一关系。如果并发提交多条申请会不会出问题回答要点更新操作使用乐观锁version字段提交时通过版本号校验冲突的请求会返回提示让用户重试。同时数据库层面给user_id type_id claim_title建了唯一索引防止同一成果被重复申报。前端动态表单是怎么实现的回答要点通过配置文件描述每个工作量类型需要的字段前端根据配置循环渲染表单项后端按固定的表单结构接收。新增类型只需要改配置不用改前后端代码。7.2 从毕设到学习源码能帮你学会什么这个项目虽然叫源码但如果你只是把源码下载下来运行一遍然后交作业收获会非常有限。我的建议是把它当做一个半成品框架自己亲手重写一遍核心模块比运行一遍有价值得多。我的学习路径推荐是这样的先看数据库脚本理解每张表为什么存在再看后端的实体类和Mapper理解表是怎么映射成Java对象的接着看Service层理解事务和业务规则的实现最后看Controller和前端页面把接口和数据流串起来。在重写的阶段你可以刻意删掉一些功能重新加上自己的理解。比如把MyBatis-Plus的LambdaQueryWrapper改成普通MyBatis XML或者加一个消息通知功能。任何源码项目只有经过你的手改动过才能变成你自己的项目不然答辩时老师让你现场改一个字段名你可能都要找半天。最后再分享一个很实在的小技巧在申报列表页加一个我的工作量汇总的卡片显示累计通过条数、累计得分、驳回次数这个功能改动很小用三条SQL就能搞定但它让系统看起来像一个有生命力的项目而不是一个作业。我在实际项目里的经验是这种小细节往往比技术大词更容易让使用者记住。