SpringBoot+Vue+MySQL工作量统计毕业设计全攻略

每年到这个时间段，就有一批为毕业设计头疼的同学。翻了半天选题清单，最后锁定在“SpringBoot+Vue+MySQL 工作量统计系统”这种经典题目上。说句实话，这类系统在技术圈里已经不算新鲜，但好在需求明确、前后端技术栈主流、工作量可控，用来作为毕业设计既不会太难收尾，又能把大学四年学的东西串起来。我也完整地把这套源码、数据库脚本、论文和部署文档从零跑通了一遍，这篇就结合我在实际搭建和二次开发过程中踩过的坑，把技术选型、表结构设计、核心接口实现、前端页面、环境部署、论文答辩这些环节逐一拆开聊聊。

这套系统能做的最核心的事，是解决团队里“谁干了多少活、怎么折算、如何考核”的问题。具体到业务上，有人录入工作项，有人审核工作量，领导层看统计报表，每一步都有数据留痕。适合的人群也很明确：计算机软件方向的本科毕业生，或者想快速搭一套管理类系统的初级开发者。如果你手里已经有了一堆源码但不知道怎么讲清楚、不知道怎么把数据库跑通，这篇内容基本就是照着操作就能落地的清单。

1. 项目定位与整体设计思路

1.1 技术栈为什么选这三件套

SpringBoot、Vue、MySQL这个组合能成为毕业设计里的“常青树”，不是没有道理的。SpringBoot是目前企业级Java后端的主流框架，它把Spring那套繁琐的XML配置收敛成了自动配置和约定优先，内置Tomcat之后连部署都不用再打war包塞到外部容器里，这对学生来说大大降低了环境搭建的门槛。Vue作为前端框架，入门曲线比React平缓，加上Element UI这套现成的组件库，做后台管理界面几乎是“拿来即用”，而且前后端分离的开发模式对应届生求职面试时也是加分项。MySQL则是关系型数据库里普及率最高的一种，Windows和Linux都能装，图形化工具又多，遇到问题随便一搜就是解决方案。

有人会问，为什么不选更“新潮”的技术栈，比如Python的Django、Flask，或者用微服务架构？这里要泼一盆冷水：毕业设计评分的核心是完整性和逻辑自洽，而不是技术炫技。工作量统计系统的数据量级根本到不了需要微服务拆分的程度，用一套过于复杂的架构反而会给论文撰写和答辩埋雷。SpringBoot+Vue+MySQL胜在结构清楚、资料丰富、运行稳定，这恰好是答辩老师最愿意看到的状态。

1.2 功能模块拆解与角色设计

我把这套系统的功能划分成六大模块：系统登录、工作量录入、工作量审核、统计报表、个人中心、系统管理。每个模块背后都有明确的业务角色支撑。通常设计三种角色：普通成员负责填报工作内容，部门主管负责审核确认，系统管理员负责用户管理、参数配置和数据维护。角色越多，权限控制就越好讲，但也不要贪多，三个角色已经足够撑起全文的核心逻辑。

工作量录入是整条业务链的起点。用户在页面上填写工作日期、所属项目、工作内容描述、工作量数值这些信息，数据落库后状态是“待审核”。这里需要注意一个细节：业务上要区分“工作量”和“工时”。工作量更宽泛，可能按任务数量计，也可能按工时折算计；工时则更精确。毕设系统里可以把两个字段都设计上，给统计部分留足扩展空间。审核环节的核心是防止弄虚作假，所以数据库中必须保留审核人、审核时间、审核意见等字段，这也是论文里“数据可追溯性”的落脚点。

1.3 业务状态机的设计

“状态”是这类系统最容易忽略又不容出错的设计点。我建议把工作量记录的状态设计为四个：草稿、待审核、已通过、已驳回。录入界面默认产生草稿，允许用户修改删除；提交后进入待审核，此时不能再编辑；主管审核后变成已通过或者驳回。驳回时必须在审核意见中写明原因，用户看到驳回状态后可以修改再次提交，这就构成一个闭环。

这个状态机看着简单，但它决定了很多接口的权限判断逻辑。比如用户只能删除“草稿”状态的数据，审核接口只能处理“待审核”状态的数据，统计接口只统计状态为“已通过”的数据。实现时可以用简单的整型字段配合注释，1是草稿、2是待审核、3是已通过、4是已驳回，这样前端下拉框渲染和后端逻辑判断都清晰。写论文时把这四个状态画成一张状态转移图，非常直观。

2. 数据库设计与核心表结构

2.1 建模思路：先画ER图再建表

动手敲SQL之前，我强烈建议先在纸上把实体关系图画出来，这是我在实际开发中养成的习惯。工作量统计系统的核心实体包括：用户、角色、工作量记录、审核记录、项目（可选）。用户和角色是多对多关系，通常用中间表连接；用户和审核记录是一对多关系，一个用户可以有多个审核记录；工作量记录表则关联用户表和项目表。

至于为什么还要一张审核记录表，而不是在工作量记录表上直接加几个审核字段？这个设计问题值得在论文里解释一下。扩展的审核记录表可以保留审核历史，支持会签、多级审核等复杂流程，同时也是“操作留痕”的证据。当然，如果项目篇幅有限，直接在工作量记录表上加审核人、审核时间字段也完全合理，知乎上有不少毕设项目就是这样做咨。我的建议是，普通本科毕设用后者足够，但要在论文里说明选择理由。

2.2 核心表字段设计参考

用户表和角色表的字段比较常规，我直接给关键字段说明。用户表包括用户ID、用户名、密码（明文不要存，至少用BCrypt加密）、真实姓名、所属部门、角色ID、创建时间、是否删除。工作量记录表是重头戏，核心字段包括记录ID、用户ID、项目ID、工作日期、工作内容描述、工作量数值、计量单位（小时/天/件）、状态、提交时间、审核人ID、审核时间、审核意见。

字段类型的选择上，有几个容易踩坑的地方要重点提醒。工作量数值建议用DECIMAL(10,2)，不要用FLOAT或DOUBLE，因为浮点数在累加统计时会产生误差，写到论文里也是减分项。状态字段用TINYINT比VARCHAR更省空间，查询效率也高。所有时间字段建议用DATETIME而不是TIMESTAMP，前者范围更宽，后者到2038年会溢出——这样的小细节提一嘴，答辩老师会觉得你考虑问题周全。再加一个“逻辑删除”字段（比如is_deleted），避免物理删除导致数据无法追溯，这是企业级开发里的常见做法。

2.3 统计SQL的写法与优化

统计功能是系统的核心亮点，也是答辩时最能体现技术含量的部分。最简单直接的统计是“按用户、按月汇总工作量”：

sql复制SELECT
    user_id,
    DATE_FORMAT(work_date, '%Y-%m') AS month,
    SUM(workload_value) AS total_workload
FROM workload_record
WHERE status = 3
GROUP BY user_id, DATE_FORMAT(work_date, '%Y-%m')
ORDER BY month DESC;

这段SQL用到了GROUP BY、DATE_FORMAT和聚合函数SUM，配合前端ECharts图表，就能画出月度工作量柱状图。如果还需要统计部门维度，可以JOIN用户表把部门字段带出来，再加一层GROUP BY。数据量小的时候没问题，但设计时要注意：统计表往往会被频繁查询，与其每次实时算全量，不如引入“统计结果表”或者“定时汇总”。毕设中用定时任务（Spring的@Scheduled注解）每天凌晨汇总一次前一天的数据，写入统计表，报表查询只读统计表，接口响应会快很多。这个优化点在论文里专门写一节，绝对是一个亮点。

3. 后端核心功能实现

3.1 项目结构分层与启动类

后端工程我用的是标准Maven项目，按照controller、service、mapper、entity、config、common分层。实体类对应数据表，Mapper接口负责数据库操作，Service层写业务逻辑，Controller层只做参数接收和结果封装。这种分层文章逻辑值得反复强调，因为它直接对应论文里的“系统设计”章节。

pom.xml里的关键依赖要列全。SpringBoot父依赖、spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java、lombok、jjwt（JWT）、hutool工具类、EasyExcel导出组件。为什么选MyBatis-Plus而不是原生MyBatis？因为Plus自带通用CRUD方法，单表操作用内置方法就够了，减少大量重复SQL；自定义统计SQL时再手写XML或注解SQL，灵活度也不受影响。如果论文里写“使用MyBatis-Plus提高开发效率，解决单表CRUD冗余问题”，这句话十有八九能戳中答辩老师的认可点。

3.2 登录鉴权与JWT令牌

登录鉴权用JWT而不是传统Session，是前后端分离架构的自然选择。JWT的原理一句话就能讲清楚：用户登录成功后，服务端生成一个带签名信息的令牌返回给前端，前端在后续请求的Header中带上这个令牌，服务端验签通过就认为是合法用户。

实现上，我建议用一个拦截器做全局登录校验，放行登录接口和静态资源，其余接口统一拦截。核心做法是写一个HandlerInterceptor，在preHandle方法里从请求头取Authorization字段，解析token，校验通过后把userId放进request的attribute中，供后续业务逻辑使用。再用WebMvcConfigurer注册这个拦截器。至于权限控制，可以在自定义的@RequireRole注解里判断角色，配合拦截器统一处理，这样Controller代码里不需要写一堆if判断。

3.3 工作量申报与审核接口

工作量录入接口建议设计成RESTful风格。前端提交的数据格式是JSON，包含用户ID（也可以从token里解析）、项目ID、工作日期、工作内容、工作量数值、计量单位。Control层接收后用Validated注解做基础参数校验，比如工作量数值必须大于0、工作日期不能是未来日期，这是防脏数据的第一道关卡。

审核接口的关键点在于状态判断和幂等性。设计上，审核操作修改工作量记录表的状态字段，同时把审核人ID、审核日期、审核意见写进表里。如果表设计时没有单独审核表，那就直接UPDATE这行记录。这里最容易出的问题是我曾经踩过的：审核接口没有判断当前状态，导致已经审核过的记录被再次审核，状态被覆盖。要解决也不难，UPDATE语句里带上状态条件：

java复制LambdaUpdateWrapper<WorkloadRecord> wrapper = new LambdaUpdateWrapper<>();
wrapper.eq(WorkloadRecord::getId, id)
       .eq(WorkloadRecord::getStatus, WorkloadStatus.PENDING.getCode());

MyBatis-Plus的UpdateWrapper支持这种带条件的更新，更新行数为0就说明记录不存在或者状态被改过，可以抛出异常提示“该记录已被审核”。

3.4 EasyExcel导出与图表数据接口

工作量报表如果只有在线图表，似乎还差点意思。我后期加了一个导出Excel的功能，使用EasyExcel一行代码就能实现。导出前先查数据，然后把每行数据封装成实体对象，调用EasyExcel的write方法写出到HttpServletResponse输出流。注意设置响应头的Content-Type为application/vnd.ms-excel，否则浏览器会直接当成二进制文件下载。

图表数据接口设计上，我定义了两个API：一个返回月度趋势数据（每月总工作量），一个返回项目占比数据（每个项目工作量的百分比）。前端分别用折线图和饼图展示。接口返回结构统一为{code: 200, data: {...}, message: "success"}，前端拿到数据后只用关注data部分，这也是前后端分离约定的一部分。写论文时可以描述这个接口为“面向可视化看板的数据服务接口”，听起来就很正规。

4. 前端Vue实现与交互细节

4.1 工程创建与目录规划

前端我用Vue CLI创建工程，选Vue 2版本。为什么不是Vue 3？并不是Vue 3不好，而是Element UI对Vue 2支持最稳定，网上报错案例也少。真要上Vue 3就得用Element Plus，语法和组件的API会有差异，对学生来说踩坑成本高。毕设求稳，我通常建议Vue 2 + Element UI，界面代码写起来非常顺手。

目录规划上，src下建api、router、store、views、components、utils这几个文件夹。api目录按业务模块拆分文件，比如user.js、record.js、statistics.js，每个文件专门存放对应的axios请求方法，方便维护。views目录放页面组件，登录页、布局页、工作量录入页、审核页、统计看板页、用户管理页。路由统一配置，通过meta字段标记页面标题和角色权限。

4.2 登录页与路由守卫

Vue实现登录页其实是常规操作，唯一要小心的是token的持久化和请求拦截。用户输入用户名密码，点击登录按钮，调用后端接口验证。成功后拿到token值，用localStorage存起来，同时用Vuex保存用户基本信息，然后跳转到首页。

路由守卫是前端权限管理的核心。beforeEach钩子里判断要跳转的路由是否需要登录权限，需要的话就检查localStorage里有没有token，没有就重定向到登录页。对已经登录的用户再访问登录页时，就重定向到首页。拦截器用axios的interceptors实现，请求发送前在Header上加Authorization，响应返回时统一处理code为401的情况，比如token过期就自动清除本地登录信息并跳回登录页。

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

4.3 表单校验与状态联动

工作量录入页面是用户打交道最多的界面，表单的交互细节决定整个系统是否“好用”。我用el-form的rules属性写了三条校验规则：工作内容必填、工作量数值必须大于0且不能超过500、工作日期必选。Element-UI的校验机制在失焦和提交时都会触发，看起来很像企业级表单。

状态联动主要体现在按钮的显隐和列表的可操作性上。待审核和已通过的记录不能让用户编辑或删除，按钮就应该隐藏。已驳回的记录要允许编辑后再次提交，所以编辑按钮对驳回状态显示。这些判断不需要写很多复杂的逻辑，提交列表接口时把状态字段一起返回，前端根据状态字段计算按钮的disabled属性或者v-if条件即可。还有一个小技巧：工作日期选择器用disabled-date属性限制不能选未来日期，比后端校验体验更好。

4.4 可视化看板与ECharts

统计看板页面我用了ECharts。它不是Vue的专属组件，所以封装了一个基础组件来管理图表的初始化和销毁，避免组件卸载后还在渲染页面。做法很简单：在mounted生命周期里初始化echarts实例，监听窗口变化事件触发resize，在destroyed前清理实例。

折线图的x轴放月份，y轴放工作量数值，数据从统计接口拿。饼图展示项目工作量占比，数据要事先按项目分组汇总。前端拿到接口返回的数据后，做一些简单的映射处理，设置好option的series字段，再setOption进去。如果是用npm安装echarts，注意按需引入模块而不是全量引入，打包体积会小很多，这个细节在写部署文档时也能提一笔。

5. 本地环境搭建与项目部署全过程

5.1 MySQL安装与初始化

部署文档是每个拿到源码的人最先看的内容，写得好不好直接影响使用体验。MySQL我建议统一用8.0版本，安装时把字符集选成utf8mb4。Windows安装版一路Next按默认即可；Linux如果是CentOS，用yum安装或者下载tar包解压后手工初始化都行。安装完成后创建学校的数据库名称——注意不要用中文和特殊符号，比如workload_db。

拿到项目后要执行数据库脚本init.sql。用Navicat或者命令行source命令导入都可以。导入之前先创建数据库，再执行脚本，避免由于重启库导致外键报错。数据库脚本里通常包含建库、建表、插入初始数据三部分，初始数据包括管理员账号、测试用户、少量工作量记录，这样前端页面打开就有内容可看，否则统计图表一片空白。检查脚本执行是否成功，最快的办法是看几张关键表的数据是否已插入：直接SELECT COUNT(*) FROM user表，如果得到大于0的结果，说明成功了。

5.2 后端打包启动与配置修改

后端项目拿到手，第一步改application.yml里的数据库连接配置。这一块大概率会出错的就是时区问题，URL里一定要带serverTimezone=Asia/Shanghai，如果用MySQL 8以上版本还得带上useSSL=false。用户名密码改成自己本地的账号密码。改完后启动SpringBoot的main方法，观察控制台日志，看到Tomcat started on port(s): 8080这行字样基本就成功启动。

如果要打包部署到服务器，直接执行mvn clean package -DskipTests，在target目录下会生成一个jar文件。用java -jar workload.jar这个命令就能运行。第一次运行前注意检查端口是否被占用，Windows下可以用netstat -ano | findstr "8080"找到占用进程，然后去任务管理器结束进程，或者直接改application.yml里的server.port换一个端口。

5.3 前端依赖安装与构建

前端的坑往往比后端多。npm install这一步因为网络原因或者其他问题导致安装失败，最常见的提示是卡住不动或者报end of JSON input错误。解决思路是换npm源，可以永久切换到淘宝镜像：npm config set registry https://registry.npmmirror.com。我实测下来这个源在应对大量依赖安装时非常稳，几乎不会因为超时中断。

依赖装完，本地开发调试用npm run serve，默认端口8080，和后端端口冲突时需要在vue.config.js里配置devServer的端口，比如改成3000。前端跟后端交互靠的是代理，devServer的proxy配置要把/api前缀的请求转发到后端的8080端口，同时后端要配置跨域允许。发布部署时执行npm run build，把dist目录放到Nginx的html目录下，再让Nginx把接口请求反向代理到SpringBoot。做一次完整的部署，整理成文档，这部分对评分帮助极大，很多答辩老师都会看部署文档是否规范。

5.4 部署常见问题速查

上面这张表我是直接从部署记录里抄出来的。每一条都是真实出现过的问题，放到部署文档的“常见问题”章节里，能够帮使用你源码的人节省大量排查时间，也是论文附录里很加分的内容。

6. 论文写作与答辩准备

6.1 论文大纲怎么定

拿到一个毕设题目后，最怕对着空白Word不知道写什么。工作量统计系统这类项目的论文结构有成熟模板，我建议按这样安排：第一章绪论（背景意义、国内外现状、主要工作），第二章相关技术介绍（SpringBoot、Vue、MySQL、前后端分离概念），第三章需求分析（用例图、业务流程、功能性需求、非功能性需求），第四章系统设计（总体架构图、功能模块设计、数据库ER图、接口设计），第五章系统实现（界面截图配代码片段），第六章系统测试（测试用例表、测试结论），第七章总结与展望。这套结构对应学校惯用的工程型论文模板，写起来不会偏。

每章的篇幅控制要有策略。第二章相关技术不要抄书，用一两句话介绍清楚再说明为什么在系统里用它即可；第四章和第五章是重点，系统架构图、E-R图、核心代码、运行截图都要放全。答辩老师爱翻的部分也恰恰是这两章，页面截图建议多放几张。

6.2 图与表的准备

论文里图片的准备要注意两点：一是清晰度，截图之前把页面放大到150%，避免小字模糊；二是图注规范，每张图下面必须有“图4-3 工作量审核界面”这样的编号和图名，去掉水印和无关信息。E-R图我建议可以用专业的绘图工具或者在线绘图工具完成，画好后导出PNG插入论文。

测试部分的表格同样重要。测试用例表按模块设计，包括用例编号、测试步骤、预期结果、实际结果、是否通过。测试数据不必真实业务数据，但数量要足够。比如工作项录入，准备10条测试数据覆盖正常填写、工作量为0、日期为未来日期、内容超长等边界情况，表格的行数自然就丰富起来，论文的“测试”章节就不会显得空洞。

6.3 答辩问题与回答思路

我整理几个答辩时高频出现的问题以及对应的回答思路。第一个问题：“你的系统解决了什么问题？”回答要点是，传统Excel统计工作量大、易出错、数据不透明，本系统实现线上申报、审核、统计一体化，做到数据可追溯。第二个问题：“为什么用JWT？”回答要点是Session在前后端分离下维护成本高，JWT无状态、易扩展，适用于分布式部署场景。第三个问题：“统计模块的优化方案？”回答要点是引入定时汇总策略，避免高频实时聚合查询。这些问题准备的思路比较直接，平时敲代码的时候多往上想一层“为什么这么设计”，答辩基本不用慌。

结尾我再补充一点真实体会：做毕业设计最重要的其实不是代码跑得多花哨，而是整套工程从头到尾能闭环。我见过太多同学手里有一份源码但数据库跑不起来、文档和代码对不上，结果答辩现场演示时在台上反复报错。如果你也打算拿这份源码做二次开发或直接使用，请务必把每个模块自己敲一遍，至少把建表SQL、核心接口、前端路由和部署流程彻底弄明白，这样才能在答辩时经得起任何追问。这套系统后续还可以扩展成实习管理、工时计费或者值班统计的变体，把工作量字段换成值班次数、把审核人换成排班管理员，业务边界就换了一个方向，移植性很好。希望这篇拆解能帮你少走一些弯路。