Spring Boot工作量统计管理系统实战：从表结构到审批流程全解析

先交代一下背景，这个项目不是凭空拍脑袋想出来的。当时部门主管最头疼的事情是：每周大家写的周报水分太大，项目进度全靠问、考核评分全靠感觉。他想上一套系统，能把每个人的任务、工时、成果量摆到台面上，让项目进度和员工产出有据可查。项目最终落地成果是一套 Spring Boot 工作量统计管理系统，带完整源码和文档，能覆盖任务下发、工作量填报、审批、统计报表几个核心环节。

如果你正准备做 Spring Boot 练手项目，或者公司内部缺一个轻量级的任务/工时管理工具，这篇文章的建模思路、实现细节和踩坑记录应该能帮你省不少时间。这套系统本身不复杂，但里面涉及的表结构设计、权限控制、报表统计、事务处理，几乎把 Java 后端日常开发的典型问题都碰了一遍，读完你可以直接照着拆分复用到自己的项目里。

1. 项目背景与需求拆解

1.1 工作量统计到底在解决什么痛点

先说个普遍现象：很多团队在考核工作量时，最终依据是员工的日报或周报。可日报周报的自由度太高，有人写三百字像写了三千字，有人干了重要的事只留下一行“修复Bug”。真正做管理的人拿到这些文本，根本没法量化，更没法跨部门对比。所以做这个系统之前，我先梳理了三个必须解决的痛点：

• 任务来源不透明，谁在什么时候接了哪个任务、做到什么程度，没有统一记录；
• 工作量缺乏原子数据，工作成果和工时对不上，后期统计全靠Excel手工拼；
• 审批和反馈链路断裂，上报内容到底认不认、修改意见是什么，缺少线上线下一致的状态记录。

因此这个系统不是简单做一个“记工时”的工具。它的核心目标是把任务派发、执行反馈、主管审核、汇总统计串成一个完整的业务闭环。管理端能随时看出谁的工作量异常偏高或偏低，项目负责人能依据实时数据调整排期，员工也能通过系统提交内容让“干过的活”不被埋没。

1.2 核心业务流程与功能模块划分

整个系统围绕一条主线展开：管理员创建人员与权限，项目负责人下发任务，执行人接收任务后按周期填报工作量和工时，主管逐条审核，审核通过的数据进入统计报表。有的团队还需要把“任务类型”和“项目名称”维度也纳入统计，方便看出人力成本都花在了哪些项目上。

我在落地时把功能拆成六个核心模块：

这套模块划分从实际复盘来看是合理的。任务管理管的是“源头”，工作量填报管的是“过程数据”，审批是“质量闸门”，统计报表是“最终出口”。四个环节缺一个，系统就又会退回 Excel 手工维护的状态。

2. 技术方案选型与架构设计

2.1 为什么选 Spring Boot 这套组合

选型时我基本没犹豫，后端直接用 Spring Boot 2.7.18。之所以定在 2.7.x 而不是 3.x，主要考虑到两个现实因素：一是很多公司生产环境 JDK 还停留在 8，Spring Boot 3 强制要求 JDK 17 起步，升上去麻烦；二是网上资料和问题排查经验最多、最稳的还是 2.7.x 这个版本段，遇到坑能更快找到解决方案。

持久层我用 MyBatis-Plus 而不是原生 MyBatis。原因很简单：简单的单表 CRUD 可以直接用 BaseMapper 内置方法，不用写大量重复 XML；统计报表这类复杂场景又能自由写 SQL，灵活度不会被框架绑死。数据库选 MySQL 8.0，因为 MySQL 8.0 对窗口函数、公用表表达式的支持更完善，做同比环比之类的报表要比 5.7 顺手很多。认证这块用 JWT + 自定义拦截器的方式，不引入 Spring Security。工作量统计系统大多是企业内网或中小团队使用，权限模型相对简单，Spring Security 那套过滤器链配置成本对这种体量来说有点重了。

前端部分用的是 Vue 2 + Element-UI，和前端同事配合时也是按前后端分离的模式联调。后端只提供 RESTful 接口，前端通过 Nginx 转发请求。这层决策给后续二次开发留了很大的便利，比如以后想换一套前端框架，后端接口完全不需要动。

2.2 数据库设计：一张“统计友好”的表结构

这个项目里我踩的最大的坑，其实不是代码，而是表结构设计。最开始我按照“人员、任务、填报记录”三张表做，结果到了报表阶段发现一个简单的按人出勤统计都要 join 四五张表，SQL 写起来痛苦，查询还慢。后来调整思路，把所有面向统计的冗余字段直接落到业务表上。

核心表我最终收敛成这六张：