SpringBoot+Vue科研工作量管理系统开发实践与部署指南

每年年底，科研秘书们最怕的活儿就是收工作量表。我在学院信息化对接群里见过太多版本——表格格式不统一，有人按套表填，有人自由发挥，审核时光是口头核对找差异就能耗一整天。后来我干脆用SpringBoot+Vue做了一套科研工作量管理系统，从成果录入、审核到工作量汇总全部线上化。后端基于SpringBoot和MyBatis，数据落在MySQL，前端用Vue和Element UI搭界面，跑通了从教师填报、科研秘书审核到院系领导看板的全流程。这篇文章不是写给人看的架构文档，而是我从需求梳理到落地部署的完整记录，适合需要做类似管理系统的人参考借鉴。

1. 需求拆解：科研工作量管理到底在管什么

做管理系统的第一件事不是建表，而是先把业务流程问清楚。我调研了学院负责科研工作的老师，也翻了往年的Excel统计模板，最后把需求收敛成四条主线：成果入库、工作量填报、分级审核、多维统计。

1.1 业务现状与痛点：从Excel表格说起

以前的工作量收集流程大概是这样的：科研处发一个Excel模板，教师往里面填论文、项目、专利、获奖，填完发给系里，系里汇总后交给学院，学院再审一遍后统一交上去。

这套流程有三个致命问题。第一是格式失控，有人把期刊名写在论文标题前面，有人把项目经费写成字符串“约50万”，等到汇总的时候根本没法做求和运算。第二是重复劳动，同一篇论文在年底考核、职称评审、绩效发放中要反复填报，数据却散落在不同人的电脑里。第三是追溯困难，审核意见在微信里来回传，过两个月再想查某条成果是谁审批的，翻聊天记录都找不到。

系统设计的第一目标就是把这套线下流程搬到线上，所以必须支持成果的多次引用、审核留痕、状态可追溯。这个需求直接影响了我后来的数据库设计——成果表和审核过程表分开，成果数据只需要录一次，工作量填报引用它的记录ID即可。

1.2 核心角色与权限边界

调研之后确定四类角色，权限边界非常明确：教师只能维护自己的成果并提交工作量；科研秘书负责审核本人所在院系的成果和工作量；院系领导可以查看全院统计数据但不能修改明细；系统管理员维护用户、角色、基础字典。

我一开始想做成一个复杂的RBAC模型，后来发现系统规模根本不需要。四类角色，四种权限，直接在JWT里带一个角色字段就够了，不用上Spring Security那套完整的ACL体系。但注意，如果是给多学院大平台做，角色配置还是建议做成可动态维护的，我这里因为固定场景所以做了简化。

1.3 工作量折算规则与审核流程

工作量本身是一个折算后的分值。以论文为例，SCI一区30分、二区25分、三区20分、四区15分、中文核心10分、一般期刊3分；项目分国家级、省部级、市厅级和校级，按负责人和参与人乘以不同系数；专利只看发明专利和实用新型，外观设计一般不给分。

这些规则必须可以配置，不能写死在代码里。我是把它们做成了字典表，涉及分值的部分用了一个notitle叫“工作量系数表”，字段是成果类型、级别、分值、备注。虽然当前版本是管理员直接改表，但至少比散落在代码里维护起来容易。

审核流程则是三审制：教师提交后，科研秘书初审核，院系领导复核，最后科研处终审。我实际落地时发现，学院规模不大，终审很多时候直接跳过，所以流程要支持可配置节点，默认走“提交-审核-通过/驳回”即可。

2. 技术栈选型：SpringBoot+Vue+MyBatis这套组合为什么靠谱

选型这件事我通常不追新，稳定、易招人、资料全这三个因素排在前面。这套系统用的技术栈如果放到三年前是标配，放到今天依然是中小型管理系统最合适的组合。

2.1 后端选型：SpringBoot管业务，MyBatis管数据

SpringBoot最大的价值是解决了Spring配置地狱。我只需要引入starter，写一个配置类，就能把数据源、事务、拦截器串起来。项目管理用Maven，依赖版本也不需要自己操心，SpringBoot的parent POM统一管理版本。

我在项目中用的是SpringBoot 2.7.x，而不是3.x。原因很简单，2.7对JDK 8的支持非常成熟，而且大量的Spring Boot Starter、第三方兼容方案都是基于2.x验证过的。如果你学习或复现这个项目，建议和我保持一致，否则遇到了奇怪的兼容性报错会非常磨人。

MyBatis我是刻意选的。Hibernate JPA功能强大，自动建表、通用方法多，但科研工作量系统中大量涉及动态条件查询和统计分组，MyBatis的XML SQL让我像写普通SQL一样控制执行逻辑，出了问题也好排查。加上System的MyBatis-Plus项目也保留了手写SQL的自由度，这套模式长期被验证是靠谱的。

2.2 前端选型：Vue+ElementUI的页面组织方式

前端选择Vue 2 + Element UI对我来说几乎不用犹豫。Vue 2生命周期清晰，适合中小型后台系统；Element UI组件库覆盖表格、表单、弹窗、日期选择这些高频组件，开发效率高。

界面结构上我采用了经典的三栏布局：顶部导航栏、左侧菜单栏、右侧内容区。路由用vue-router 3.x，状态管理用Vuex。这套组合在后台管理系统里的生态非常成熟，遇到问题搜一下基本都有现成答案。

很多同学会纠结Vue 2和Vue 3到底用哪个。我建议如果是为了快速复现毕业设计和课程项目，Vue 2 + Element UI的成熟稳妥；如果是商业项目或长期迭代，Vue 3 + Ant Design Vue或Element Plus是更好的选择。但我这个项目要稳定落地，最终选了Vue 2。

2.3 版本匹配与运行环境：踩坑最少的一套配置

版本匹配是整个项目最容易出问题的地方，我把最终跑通的配置列成了一张表：

这组版本不是我随便挑的，是实测下来兼容性最省心的一套。如果你用了SpringBoot 3.x和JDK 17，那MyBatis和部分前端构建工具就要跟着换版本，改动成本会上升不少。

3. 数据库表结构：工作量相关表的建模与字段设计

数据库设计的好坏决定了后端代码写起来顺不顺手。我在第一版把成果和工作量混在一张表里，后来审核流程一加就崩了，才明白主表和明细表必须分开。

3.1 用户、角色、院系这三张基础表

用户表是系统的基础，字段里除了账号密码，还必须有工号、姓名、职称、所属院系ID。密码不要存明文，用BCrypt加密后存储。用户状态字段用于禁用离职人员。

sql复制CREATE TABLE sys_user (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  username VARCHAR(50) NOT NULL UNIQUE,
  password VARCHAR(100) NOT NULL,
  real_name VARCHAR(50) NOT NULL,
  employee_no VARCHAR(20),
  title VARCHAR(20) COMMENT '职称',
  college_id BIGINT,
  phone VARCHAR(20),
  email VARCHAR(50),
  status TINYINT DEFAULT 1 COMMENT '1启用 0禁用',
  create_time DATETIME,
  update_time DATETIME
);

角色表不需要设计得很重，一个角色编码、一个角色名称就够。用户和角色的关联表负责多对多关系，因为一个教师可能同时是科研秘书和管理员。

院系表只有三个字段：ID、学院编码、学院名称。为什么还要单独建表？因为后续所有统计都要按学院维度分组，有这张表之后一条JOIN就能拿到学院名，不用在代码里维护学院字典。

3.2 成果类业务表：项目、论文、专利的公共设计思路

成果表的设计核心不是字段多，而是把“用于计算工作量”的信息抓准。论文表至少要有：标题、期刊名称、期刊级别（SCI分区/EI/核心/普刊）、发表日期、作者排序、是否通讯作者、检索收录情况。

sql复制CREATE TABLE biz_paper (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT NOT NULL COMMENT '录入人',
  paper_title VARCHAR(200) NOT NULL,
  journal_name VARCHAR(200),
  journal_level VARCHAR(20) COMMENT 'SCI1/SCI2/SCI3/SCI4/EI/CORE/NORMAL',
  author_order VARCHAR(20) COMMENT '第一作者/通讯作者/其他',
  is_sci TINYINT DEFAULT 0,
  publish_date DATE,
  score DECIMAL(5,2) DEFAULT 0 COMMENT '折算分值',
  create_time DATETIME
);

项目表比较重，因为项目有起止时间、经费金额、项目级别、负责人和成员。经费金额用DECIMAL而不是VARCHAR，不然统计总经费的时候你就知道有多痛苦了。项目成员这块我做了一个多选字段存成员ID的逗号分隔字符串，虽然不符合严格范式，但查询简单，小系统这样用完全没毛病。

专利表字段相对少：专利名称、专利号、专利类型、授权公告日期、发明人。重点是专利号唯一，如果忽略唯一索引，同一个专利会被重复录入，工作量统计就会虚高。

3.3 工作量主表+明细表：为什么要拆成两张表

工作量填报是整条业务的核心。教师提交的考核批次对应一条工作量主记录，里面存年度、申请人、总得分、审核状态；主记录下面挂若干明细，每一条明细链接到一篇论文或一个项目。

为什么不直接在成果表上加审核状态？因为同一篇论文可以被用于年度考核工作量，也可以用于职称评审，状态和批次不同，直接加字段会让表结构变得非常混乱。拆开之后，成果表只管事实，工作量主表管批次和流程，工作量明细表管关联关系。这个设计让我在后期加“每季度工作量小结”功能时几乎没有改动成果表，新增批次类型就完成了。

审核过程表记录每一次审核操作：谁审核的、审核结果是什么、备注是什么、什么时间审核的。这几个字段就够审计追踪用了，不必过度设计。

3.4 初始化脚本中的关键细节

建表SQL里我踩过一个坑：MySQL 8的默认排序规则是utf8mb4_0900_ai_ci，如果建库时用utf8mb4_general_ci，后面一些特殊字符报错时会很莫名其妙。建议建库时明确指定：

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

另外备份数据和复用数据时，最好提供一份初始数据SQL，包含默认管理员账号、基础角色、学院列表、工作量系数表。别人拿到项目后，导入这份SQL就能登录系统，体验会好非常多。

4. 后端实现：SpringBoot接口与审核流程的核心逻辑

后端代码我按模块分包：controller、service、mapper、entity、config、common。看着普通，但每个模块都有几个值得说的设计点。

4.1 统一返回结构让前后端联调少吵架

我定义了一个Result对象，所有接口统一返回code、message、data三件套。前端axios拦截器里识别code，不等于200时直接Message.error，不再每个页面单独弹错。

java复制public class Result<T> {
    private Integer code;
    private String message;
    private T data;
    public static <T> Result<T> success(T data) { ... }
    public static <T> Result<T> error(String msg) { ... }
}

全局异常处理用@RestControllerAdvice，捕获业务异常、参数校验异常、兜底异常。我最开始写接口时随心所欲，有的返回字符串有的返回对象，后来统一重新扫了一遍，前端处理逻辑反而简单了。这个规范应该在项目第一天就定下来。

4.2 JWT认证：没必要把Spring Security全套搬进来

登录接口验证用户名密码成功后，把用户ID、用户名、角色编码放进一个JWT返回给前端。前端每次请求在Header里带Authorization: Bearer token，后端用一个拦截器拦截非白名单请求，解析token并写入ThreadLocal。

java复制public class JwtInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String token = request.getHeader("Authorization");
        // 校验token，失败返回401
        // 成功解析用户信息存入UserContext
        return true;
    }
}

为什么不用完整版的Spring Security？因为系统只是单一后台管理，不涉及OAuth2、社交登录、细粒度方法级权限。一个Interceptor加一个注解就能解决绝大部分权限问题，引入Spring Security会让配置复杂度成倍上升。我做技术选型的原则是够用就好。

权限控制用角色编码加自定义注解实现：@RequireRole("ADMIN") 标注在需要管理员权限的接口上，拦截器里判断当前用户角色是否匹配。这样既简单又直观，代码评审时一眼能看懂。

4.3 MyBatis动态SQL的实战写法

工作量系统里最常用的就是条件分页查询：按成果类型筛选、按年度筛选、按状态筛选。MyBatis的标签配合判断，比拼接字符串干净得多，而且天然防SQL注入。

xml复制<select id="selectPaperList" resultType="com.example.entity.Paper">
  SELECT * FROM biz_paper
  <where>
    <if test="paperTitle != null and paperTitle != ''">
      AND paper_title LIKE CONCAT('%', #{paperTitle}, '%')
    </if>
    <if test="journalLevel != null and journalLevel != ''">
      AND journal_level = #{journalLevel}
    </if>
    <if test="userId != null">
      AND user_id = #{userId}
    </if>
  </where>
  ORDER BY publish_date DESC
</select>

配置文件里一定记得开关下划线转驼峰，否则数据库的user_id映射不到实体类的userId：

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

分页我用PageHelper，三行代码搞定。但注意PageHelper的依赖版本需要匹配MyBatis Starter版本，版本不一致时会出现分页不生效或SQL被注入额外count语句的诡异问题。

4.4 审核状态机的实现

工作量审核状态我定义为枚举：DRAFT(0,草稿)、SUBMITTED(1,已提交)、APPROVED(2,已通过)、REJECTED(3,已驳回)。状态流转只能在Service层通过方法调用完成，controller不能直接改状态字段。

java复制public void submit(Long workloadId) {
    Workload w = getById(workloadId);
    if (w.getStatus() != WorkloadStatus.DRAFT.getCode()) {
        throw new BizException("当前状态不可提交");
    }
    w.setStatus(WorkloadStatus.SUBMITTED.getCode());
    updateById(w);
}

审核通过时，要同步计算主表的总得分并写入统计汇总表。这里涉及事务，我会在Service方法上加@Transactional，保证主表和汇总表同时更新成功。如果漏掉事务，审核通过但汇总分没更新，统计报表就会出大问题。

统计接口的SQL也是亮点：

sql复制SELECT c.college_name, SUM(w.total_score) AS total_score
FROM biz_workload w
LEFT JOIN sys_user u ON w.user_id = u.id
LEFT JOIN sys_college c ON u.college_id = c.id
WHERE w.status = 2 AND w.apply_year = #{year}
GROUP BY c.college_id
ORDER BY total_score DESC

这个查询把工作量表、用户表、院系表关联起来，一条语句就完成院系排名。刚开始我用Java代码在内存里分组，数据量一上万就卡，改成SQL之后秒出结果。能用数据库算的绝不用应用层算，这是做管理系统的一个基本觉悟。

5. 前端Vue页面：填报、审核、统计三块核心交互的实现思路

前端我划分成几个核心页面：登录页、Dashboard首页、成果管理、工作量填报、审核列表、统计报表。这里挑三块讲清楚实现细节。

5.1 登录态处理和路由守卫

前端登录页把用户名密码交给后端，后端返回token。前端把token存在localStorage，同时用Vuex存储用户基本信息，比如姓名、角色。编码上注意localStorage是持久化的，页面刷新后用户还保留登录态，但如果后端token有效期过了，接口会返回401，这时需要强制跳回登录页。

路由守卫写在router.beforeEach里：

javascript复制router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token');
  if (to.path !== '/login' && !token) {
    next('/login');
  } else {
    next();
  }
});

axios拦截器的完整写法是：请求拦截器统一加Authorization头，响应拦截器判断backend返回的code或者HTTP状态码，为401时清掉localStorage并跳转登录页。这么做了之后，token过期这个事对用户几乎无感知，重新登录一次就行。

5.2 填报页面的表单校验

成果填报的表单要分类型处理。论文有标题、期刊、级别、发表日期；项目有项目名、类型、经费、起止时间；专利有专利号、类型、授权日。我封装了三个子表单组件，父组件根据成果类型动态渲染对应表单。

element-ui的el-form自带校验规则，rules里定义required、pattern、message就行。特别注意那些会影响分值的字段，比如期刊级别，必须用select下拉选择，如果提供free input就会有人填“SCI一区顶刊”也能通过校验，统计出来全是脏数据。

工作量填报页的操作逻辑是：勾选本年度要申报的成果列表，点击“生成工作量”，前端把成果ID数组提交给后端，后端在事务里生成主表和明细。这个交互比让用户一条条手动填score合理得多，也避免用户自己篡改分值——分值应该由系统根据规则系数表自动计算。

5.3 审核页面的操作逻辑

审核列表页我用了el-table加多条件筛选，默认只展示status=1（已提交）的记录。科研秘书登录后只能看到自己院系的记录，管理员看全局。

单条审查时，点击展开行能看到该工作量下的全部成果明细。这一步很重要，否则审核人还要跳转好几个页面才能核对，效率和线下Excel差不多。审核按钮区有两个：通过和驳回，驳回时必须填写原因，前端把reason字段设为必填，防止审核员一句话不说就退回去。

驳回后教师登录系统，在“我的提交”里能看到被驳回的批次和原因，修改后可重新提交。这个闭环在状态机里已经设计好了，前端只是调用submit接口把状态从REJECTED变回SUBMITTED。

5.4 统计看板和ECharts的对接

统计页我用了ECharts柱状图、折线图和饼图，对应的数据都是后端统计接口返回的。

柱状图用来展示各院系年度总工作量对比，前端只需要把接口返回的数组拆成name和value两个数组直接塞给option.series[0].data。折线图看近五年全院工作量的趋势，饼图看成果类型的分布占比。

一个容易忽略的细节是，图表容器div的宽高。ECharts初始化时如果容器display:none或者高度为0，图表渲染出来就是一片空白。我的解决方法是tab切换后调用chart.resize()，或者用nextTick再初始化。这个坑看起来小，实际排查的时候很浪费时间。

统计接口的数据缓存也值得说一下。工作量统计是典型的读多写少的场景，但本项目规模不大，加Redis缓存反而增加部署复杂度，我直接每次都查数据库，查询本身已经通过索引优化过，体验完全能接受。

6. 打包部署与真实踩坑：从源码到可运行的最后一公里

很多项目代码能写出来，但打包部署这关会卡住一大批人。我把完整的部署流程和实际遇到的问题整理一下。

6.1 后端Maven打包与MySQL初始化

后端打包命令非常简单：

bash复制mvn clean package -DskipTests

打包完成后，target目录下会出现一个jar包。使用java -jar直接运行即可，但注意生产环境建议指定配置文件：

bash复制java -jar workload-system.jar --spring.profiles.active=prod

application-prod.yml里配置数据源：

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/workload_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false
    username: root
    password: yourpassword
    driver-class-name: com.mysql.cj.jdbc.Driver

MySQL初始化这一步最常见的问题是版本差异。如果你本地装的是MySQL 5.7，而初始化脚本是MySQL 8语法，直接用source命令导入会报语法错误。我的脚本里用到了utf8mb4和COMMENT 'xxx'，在MySQL 5.7里也支持，但还是要优先保持本地环境与脚本版本一致。

初始化命令：

bash复制mysql -u root -p < init.sql

导入成功的标志是最后没有报错，且sys_user表里有初始管理员记录。如果admin用户没进去，查一下auth字段是否为空、密码是否被加密。我提供的导入SQL里预置了一个BCrypt加密后的密码“admin123”，登录后记得立即改密码。

6.2 前端打包与Nginx配置

前端打包：

bash复制npm install
npm run build

dist目录里的静态文件部署到Nginx。但有个关键问题是用history模式路由时，用户直接访问某个子路径会404，需要在Nginx里配置try_files：

nginx复制server {
    listen 80;
    server_name yourdomain.com;
    root /data/www/workload-web;
    index index.html;

    location / {
        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;
    }
}

把/api开头的请求反向代理到后端8080端口，这样前端代码里写相对路径/api/xxx，不用关心实际后端在哪台机器，发布和迁移都方便。

6.3 高频踩坑：跨域、时区、依赖版本

跨域是前后端分离最容易遇到的第一道墙。后端写了CorsFilter配置类，放行所有来源，开发环境开着没问题，但上线前最好收窄到具体的域名。我遇到过一种诡异情况：配置了CorsFilter好像没用，后来发现是SpringBoot的跨域配置和Spring Security的跨域配置冲突，二选一保留就行。

时区问题也值得专门说。MySQL连接串里没有serverTimezone参数时，日期字段查出来会差8个小时。这个我在业务层对不上时间时排查了很久，最后在连接串上加了serverTimezone=Asia/Shanghai解决。

依赖版本冲突我踩过一次比较大的坑：pagehelper-spring-boot-starter和mybatis-spring-boot-starter版本不兼容，导致分页查询不生效。后来我把MyBatis Starter降到2.3.x，PageHelper Starter用1.4.x，问题才消失。版本这件事，建议直接照着我前面表格里的来，别自己混搭。

前端npm install时如果报错，优先检查Node版本。Vue CLI 4不支持Node 17以上，也不支持Node 12以下。同时不要忽略npm镜像配置，用默认仓库在有些网络环境下装element-ui和echarts会慢到让人崩溃，换成国内镜像能快十倍。

7. 个人体会与这套系统的扩展方向

做完这套系统，我最大的体会是：工作量管理系统的复杂度不在代码，而在规则建模。谁的成果怎么算分、审核流程走几级、统计口径按年度还是按自然年，这些问题想清楚，数据库表和代码逻辑都能顺理成章地设计出来。

代码部分我自己觉得最有价值的分层思路是：成果表和工作量表分离。很多新手喜欢直接在成果表上加一个审核状态字段，做第一版很快，但到后面加新批次、新流程时，改表结构改到头皮发麻。先用好主表明细表这个经典模式，后面扩展需求会轻松很多。

扩展方向我实际盘了一下，有四块比较值得做。第一是Excel导入导出，教师已经填在表格里的历史数据需要一个批量导入通道，同时工作量审核通过后要能导出成标准的汇总Excel；第二是消息提醒，教师提交被驳回后系统里要有待办提示，最好还能邮件通知；第三是集成MinIO做附件管理，论文PDF、项目合同扫描件这种证明材料不能只存路径，用对象存储统一管理更可靠；第四是接入统一身份认证，如果学校已经有统一门户，可以把登录替换成CAS或OAuth2协议，省去每次建账号的麻烦。

最后分享一个我在开发过程中发现的小技巧：开发阶段把SpringBoot日志级别调到DEBUG，MyBatis会把执行的SQL完整打印出来，调参和排错都非常方便。很多隐藏的问题，比如条件查询查不出数据、分页异常，看一眼SQL输出心里就有数了。上线前再把日志级别调回INFO，避免影响性能。

这套系统到这一步就算完整落地了，希望这篇记录能帮你少走一些弯路。