工作量统计这个需求大部分团队一开始想的都是做打卡或者考勤。真做下去才发现不对——打卡只能记录人来了根本记录不了人干了什么。我去年帮一个研发团队做内部工具时需求方一开始就说要看每个人每天在做什么、做了多少东西后来我们把需求收敛成了三块任务记录、工时填报、产出统计。这篇文章就把这套Java SpringBootVue3MyBatis 工作量统计系统的完整设计思路和实现过程整理出来包括数据库表怎么设计、统计SQL怎么组织、Vue3前端怎么展示、前后端分离项目怎么部署以及我在实际开发中踩过的一些坑。这个系统适合谁参考如果你正在给中小团队开发内部效率工具或者准备做一套带权限管理、数据统计的后台管理系统或者刚接触前后端分离开发想找一个完整项目来拆解学习这篇内容应该都能帮上你。代码层面我会尽量给出关键示例但更重要的是一开始的需求分析和表结构设计——这块想清楚了后面写代码反而很快。1. 工作量统计到底要解决什么问题1.1 为什么不是打卡系统很多人在听到工作量统计系统时第一反应是做一个上下班打卡的功能。但实际使用场景里打卡数据只能回答员工在不在工位上回答不了项目进度怎么样每个人的负荷是不是均衡工时花在了哪些任务上这些问题。我做需求调研的时候跟团队负责人聊了很久最终明确了这个系统的核心定位它是一个以任务和工时为中心的数据收集工具。每个成员把自己在一个时间段内处理的任务、花费的工时、完成状态记录下来系统再对这些原始数据进行聚合统计输出个人工作量报表、团队负载情况、任务完成率等结果。所以整个系统我们再细分核心模块只有四个工作量填报成员每天选择任务、填写工时和处理状态任务管理把零散的需求、bug、临时事项抽象成任务对象统计报表按时间、部门、个人、任务类型等多维度汇总工时和产出权限与用户管理区分管理员、部门负责人、普通成员三种角色。这套东西的价值不在于管住人而在于让管理者拿到数据之后能辅助决策——比如这个月团队哪个方向投入的工时最多、下个迭代还有没有富余人力、某个人是不是连续加班超过了合理阈值。1.2 统计口径和业务规则系统开发之前必须先统一口径这是最容易后期返工的点。我和需求方定了下面几组规则工时颗粒度最小单位为0.5小时一天填报上限由管理员配置默认8小时避免出现一小时填20小时的失真数据任务状态流转待处理、处理中、已完成、已关闭只有已完成才计入完成率统计维度按日某天个人总工时、按周自然周汇总、按月自然月汇总维度包括人员、部门、任务类型、项目名称数据归属普通成员只能查看和填报自己的数据部门负责人可以查看本部门汇总数据管理员可以看全局报表并管理用户与任务。这些规则看起来简单但直接影响后面的表结构和SQL怎么写。比如半天任务和跨天任务怎么处理我们选择了一张工时表对一天内的多个任务分别记录跨天任务拆成多条记录——这样统计SQL会简单非常多也不容易出错。2. 技术选型背后的真实理由2.1 为什么还是SpringBootMyBatis这套后端技术组合被说了很多年但我依然在把它作为新项目首选。原因很实在SpringBoot的自动配置和内置容器让项目从创建到启动只需要几分钟不需要像早期Spring那样写一堆XML配置配合Maven管理依赖团队的同事接手项目成本极低。MyBatis在统计报表这个场景下比JPA更顺手。工作量统计系统里有大量的动态SQL查询条件可能是时间范围、部门ID、任务类型、人员ID的组合。用MyBatis的where和if标签可以很优雅地拼接条件SQL的执行计划也能直接控制方便针对大数据量做索引优化。JPA虽然开发简单但遇到复杂统计查询时生成的SQL不一定高效调试成本反而高。下面这个依赖组合我实测下来最省心parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.2/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependenciesSpringBoot版本我没有直接上3.x是因为当时团队里部分中间件客户端还没完全适配Jakarta命名空间为了少踩坑2.7.x配合JDK8足够稳定。如果你的项目是全新的JDK17SpringBoot3也可以但注意MyBatis相关starter的版本别选错。2.2 Vue3带来的前端效率提升前端选择Vue3的理由很直接Composition API让组件逻辑的复用和整理比Vue2的Options API舒服太多。工作量填报页、统计报表页、用户管理页之间有大量相似逻辑比如日期范围选择、表格数据加载、导出操作用composables把这些逻辑抽成函数在多个组件里直接调用代码量减少了很多。配合Vite创建项目即时启动速度明显优于webpack开发阶段改代码热更新几乎无感。UI组件库我选了Element Plus表格、表单校验、日期选择器这些常用组件开箱即用骨架搭起来很快。前端项目的初始化我推荐用Vite的官方模板npm create vitelatest workload-ui -- --template vue cd workload-ui npm install element-plus echarts axios pinia vue-router2.3 前后端分离的部署取舍既然定了前后端分离部署就是两套产物后端一个Jar包前端构建出的静态文件。生产环境里最常见的做法是前端静态文件交给Nginx托管后端接口单独跑一个端口通过Nginx配置反向代理。开发环境则用Vite的proxy把/api转发到后端的8080端口这样前后端代码和调试都在本机完成不需要额外处理跨域浏览器请求的是同一个前端服务地址。虽然SpringBoot也可以直接托管前端静态资源但那样做就失去了前后端分离的独立性不利于前端独立迭代部署。我的取舍是**开发完全分离生产看团队运维习惯。**如果团队只有一台小服务器直接把前端dist包复制到SpringBoot的static目录也是可以的只是代码仓库和部署流程需要额外注意。3. 数据库表结构设计工作量数据的根基3.1 用户、角色与部门工作量统计离不开组织维度第一组核心表就是用户表、角色表、部门表。这里我不建议把角色和部门混在一个字段里统计SQL需要按部门聚合时分开设计能让JOIN变得简单清晰。CREATE TABLE sys_user ( id bigint NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登录账号, password varchar(100) NOT NULL COMMENT BCrypt加密, real_name varchar(50) DEFAULT NULL COMMENT 姓名, dept_id bigint DEFAULT NULL COMMENT 部门id, status tinyint DEFAULT 1 COMMENT 1启用 0禁用, create_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_dept_id (dept_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表; CREATE TABLE sys_role ( id bigint NOT NULL AUTO_INCREMENT, role_code varchar(50) DEFAULT NULL COMMENT ADMIN/MANAGER/USER, role_name varchar(50) DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT角色表; CREATE TABLE sys_user_role ( user_id bigint NOT NULL, role_id bigint NOT NULL, PRIMARY KEY (user_id,role_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户角色关联表;密码存储一定要用BCrypt加密Spring Security的BCryptPasswordEncoder直接用就可以。我在开发过程中见过很多内部系统明文存密码一旦数据库泄露就是事故这个成本没必要省。3.2 任务表与工时记录表这两张表是整个系统的核心。任务表存任务的元信息工时表存成员每天在任务上花费的时间记录。CREATE TABLE task ( id bigint NOT NULL AUTO_INCREMENT, task_name varchar(200) DEFAULT NULL COMMENT 任务名称, task_type varchar(50) DEFAULT NULL COMMENT 类型需求/缺陷/运维/其他, project_id bigint DEFAULT NULL COMMENT 所属项目, assignee_id bigint DEFAULT NULL COMMENT 负责人, status tinyint DEFAULT 0 COMMENT 0待处理 1处理中 2已完成 3已关闭, priority tinyint DEFAULT 2 COMMENT 1高 2中 3低, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_assignee (assignee_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT任务表; CREATE TABLE work_log ( id bigint NOT NULL AUTO_INCREMENT, user_id bigint NOT NULL COMMENT 填报人, task_id bigint NOT NULL COMMENT 关联任务, work_date date NOT NULL COMMENT 工作日, hours decimal(4,1) NOT NULL COMMENT 工时, description varchar(500) DEFAULT NULL COMMENT 工作说明, create_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_user_date (user_id,work_date), KEY idx_task_date (task_id,work_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT工时记录表;工时表的核心查询场景是查某个人某段时间的工时总和查某个任务累计消耗的工时。所以user_id work_date和task_id work_date这两组复合索引是必须的否则统计报表一跑起来百万条数据之后查询就会明显变慢。3.3 一个容易被忽视的冗余设计任务统计完成率的时候如果实时去count任务表里status为已完成的记录在数据量大、查询条件多时效率并不高。我选择在项目表、任务表上增加一个冗余字段completed_count每次任务状态变更时由后端同步更新——把统计压力分摊到写操作上读操作只需要SUM一个字段。这个设计对中小型系统非常实用统计SQL可以直接从关联两张表做聚合变成单表SUM响应速度快一倍以上。CREATE TABLE project ( id bigint NOT NULL AUTO_INCREMENT, project_name varchar(100) DEFAULT NULL, total_task_count int DEFAULT 0, completed_task_count int DEFAULT 0, total_work_hours decimal(10,1) DEFAULT 0.0, create_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT项目统计汇总表;这样的冗余设计带来了一个额外的好处首页仪表盘要显示所有项目总工时、总任务数、完成率直接查询个位数的项目行就能得到不需要实时扫描全库的work_log和task。4. 后端核心实现认证权限与统计SQL4.1 JWT认证与角色权限控制工作量统计系统里普通用户只能看自己的数据部门负责人能看本部门汇总管理员全量可见。这个控制如果在每个接口里写if判断会非常零散。我用Spring Security JWT统一处理。前端登录成功后拿到token后续每个请求在Header里带上Authorization: Bearer token。后端自定义一个过滤器解析token把用户ID存入SecurityContext再配合RequiresPermissions这类自定义注解做接口级权限控制逻辑很集中。实际开发里我踩过一个坑Spring Security的过滤器链执行顺序和自定义过滤器冲突导致token还没解析接口就返回401了。解决方式是给自定义过滤器加上setOrder(0)确保它在Spring Security的认证过滤器之前执行。排查这个问题花了我一下午最后是在日志里看到No authentication entry point才发现是排序问题。4.2 MyBatis动态SQL实现多维度统计统计报表的查询条件是典型的动态组合查询。拿个人月度工作量统计这个页面来举例前端可以组合的选择有月份、部门、人员、任务类型。后端Mapper接收一个查询条件对象在XML里这样写select idselectWorkloadStats resultTypemap SELECT u.real_name AS realName, d.dept_name AS deptName, IFNULL(SUM(wl.hours), 0) AS totalHours, COUNT(DISTINCT wl.task_id) AS taskCount, SUM(CASE WHEN t.status 2 THEN 1 ELSE 0 END) AS completedCount FROM work_log wl INNER JOIN sys_user u ON wl.user_id u.id LEFT JOIN sys_dept d ON u.dept_id d.id LEFT JOIN task t ON wl.task_id t.id where if testmonth ! null and month ! DATE_FORMAT(wl.work_date, %Y-%m) #{month} /if if testdeptId ! null AND u.dept_id #{deptId} /if if testuserId ! null AND wl.user_id #{userId} /if if testtaskType ! null and taskType ! AND t.task_type #{taskType} /if /where GROUP BY u.id, d.id ORDER BY totalHours DESC /select几个关键点说明一下用where代替trimMyBatis的where标签会自动去掉第一个and前缀我早期习惯在if里写where 11后来发现where标签更规范SQL也更干净LEFT JOIN sys_dept有人可能会把部门也去掉说一张用户表就够了但在报表页面要显示部门名称没有这个JOIN就需要在前端做映射反而麻烦DATE_FORMAT(wl.work_date, %Y-%m)按月份匹配日期字段注意这个函数会导致work_date上的索引失效。如果数据量上来之后变慢可以改成参数传startDate和endDate两个字段用wl.work_date #{startDate} AND wl.work_date #{endDate}这样就能命中索引。4.3 统计数据实时性问题的处理方案工作量统计系统对实时性要求很高用户刚填完一条工时马上刷新报表就希望看到最新结果。所以不能像数仓那样做离线聚合必须直接查实时表。在前面3.3节的冗余设计基础上我采用了实时计数为主定时任务兜底的方案用户在录入/修改/删除工时记录时同步更新project表的汇总字段每天凌晨再用一个定时任务重算全量数据防止某个环节漏更新造成数据漂移。Component public class WorkloadStatsReloadTask { Scheduled(cron 0 30 1 * * ?) public void reloadAllStats() { // 按项目分组重算总工时和完成数量 ListProject projects projectMapper.selectAll(); for (Project project : projects) { MapString, Object stats workLogMapper.selectStatsByProject(project.getId()); project.setTotalWorkHours(...); project.setCompletedTaskCount(...); projectMapper.updateById(project); } } }这个定时任务我用Spring自带的Scheduled就可以不需要额外引入分布式任务调度框架对这个小系统来说已经足够。注意开发阶段要把定时器关掉或加上开关否则改了测试数据半夜自动重算反而干扰排查。5. Vue3前端从页面骨架到数据可视化5.1 页面路由与权限菜单前端路由设定了四个主页面仪表盘、工作量填报、统计报表、系统管理。用户登录后根据后端返回的权限标识动态生成菜单和路由避免在接口层面暴露无权访问的页面。// router/index.js import { createRouter, createWebHistory } from vue-router const routes [ { path: /login, component: () import(/views/Login.vue) }, { path: /, component: () import(/layout/Layout.vue), children: [ { path: dashboard, component: () import(/views/Dashboard.vue), meta: { title: 工作台 } }, { path: worklog, component: () import(/views/WorkLog.vue), meta: { title: 工作量填报 } }, { path: stats, component: () import(/views/Stats.vue), meta: { title: 统计报表 } }, { path: system, component: () import(/views/System.vue), meta: { title: 系统管理, roles: [ADMIN] } } ] } ]路由懒加载对这类后台系统很友好首屏只加载必要的组件其他页面在访问时才动态导入打包体积也能分散开。5.2 数据可视化ECharts接入与容器问题统计报表页面我用了ECharts画折线图个人月度工时趋势和柱状图部门工作量对比。ECharts是功能最全的图表库上手成本低文档也丰富。接入方式就是先安装依赖再在组件里初始化实例script setup import * as echarts from echarts import { onMounted, ref } from vue const chartRef ref(null) const trendData ref([]) onMounted(() { const chart echarts.init(chartRef.value) chart.setOption({ tooltip: { trigger: axis }, xAxis: { type: category, data: [3月, 4月, 5月, 6月] }, yAxis: { type: value, name: 工时 }, series: [{ name: 个人工时, type: line, data: trendData.value, smooth: true }] }) }) /script template div refchartRef stylewidth: 100%; height: 400px;/div /template这里要重点提醒ECharts在v-if控制的隐藏容器里初始化时宽度会变成0。我在写统计页时因为一个月度/周度切换用了v-if结果图表死活不显示控制台报错也没有最后发现是容器宽度为0。解决办法有两个一是用v-show代替v-if二是初始化后手动调用chart.resize()。我后来统一采用v-show逻辑更简单。5.3 axios封装与接口联调前端所有接口请求我封装在一个axios实例里统一处理baseURL、token注入、错误提示和响应拦截。这里有一个容易被忽略的点Excel导出请求不能走同一套JSON解析。导出工作量报表时后端直接返回文件流如果用统一拦截器去解析JSON导出就会失败。我额外封装了一个exportFile方法设置responseType: blob并单独处理。// api/request.js import axios from axios import { ElMessage } from element-plus 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 response.data, error { ElMessage.error(error.response?.data?.message || 请求失败) return Promise.reject(error) } )开发环境下配Vite代理时/api会转发到后端8080生产环境则是Nginx把/api反向代理到SpringBoot服务。这样前端代码不用关心后端地址变化环境差异只在部署配置里体现。6. 前后端联调与部署实战6.1 跨域问题与开发代理配置前后端分离后开发中的跨域问题其实很好解决不需要在后端全局开启CORS只需要在Vite配置文件里加一行proxy// vite.config.js export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })但生产环境用Nginx时反向代理配置更需要注意细节。我一开始只做了location /指向dist目录忘了配location /api/的代理结果页面能打开接口全部404。正确配置是这样的server { listen 80; server_name your-domain.com; root /var/www/your-project/dist; index 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; } location / { try_files $uri $uri/ /index.html; } }注意最后一个try_files配置是必须的否则用户在某个页面刷新时Nginx会尝试找对应的物理文件找不到就报404前端路由就白搭了。6.2 后端打包与MySQL时区后端用Maven打包mvn clean package -DskipTests打出来的Jar包在服务器上通过nohup java -jar xxx.jar 启动。这里提醒几个生产环境常见的隐患MySQL连接串里一定要加serverTimezone参数。不加的情况下如果服务器和MySQL全局时区不是东八区你写入work_date时可能出现看似日期没变但时间错了8小时的怪异问题。我最稳妥的做法是在JDBC连接串里显式指定jdbc:mysql://127.0.0.1:3306/workload_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseuseSSLfalse我得说明一下本地开发没有SSL证书时不关掉这个参数MySQL 8的驱动会直接拒绝连接报Communications link failure。生产如果有SSL需求再打开没有就关掉没必要给自己找麻烦。6.3 我在联调阶段踩过的主要坑第一是日期传参格式不统一。前端日期选择器默认输出的是YYYY-MM-DD但我一开始在Vue3组件里没有格式化直接传了个Date对象后端DateTimeFormat解析失败接口一直报400。后面统一让前端把日期参数全部转成字符串后端还用String接收再手动解析彻底消掉了这类的格式问题。第二是统计SQL中SUM结果为空导致Java空指针。用SUM(wl.hours)时如果该条件下没有任何记录返回的sum是NULL而不是0Java代码里直接get(totalHours)就NPE了。我后来在SQL里用IFNULL(SUM(wl.hours), 0)前端拿到的一定是数字。第三是数据库连接池在低并发时默认连接不够用的假象。项目刚上线时同时在线人数不多但系统偶尔报连接超时。排查下来发现是HikariCP的默认maximum-pool-size是10统计报表页面刷新频繁时几十个请求排队就把连接池占满了。我调成maximum-pool-size: 30之后问题消失。这种问题不好排查只能靠经验提前配置好合理的连接池参数。第四是Excel导出中文文件名乱码。SpringBoot返回Content-Disposition头时如果文件名是中文需要做URL编码String fileName URLEncoder.encode(工作量统计报表.xlsx, UTF-8); response.setHeader(Content-Disposition, attachment; filename fileName);前端拿到blob后用URL.createObjectURL下载这一步我见过很多老同事漏掉编码直接乱码的。7. 这套系统后续可以扩展的方向开发完这个系统之后我一直在思考它后续的扩展空间。最直接的方向是接入消息通知模块——成员提交工时后自动通知负责人负责人审批后通知成员让系统不只是数据记录工具还能形成简单的审批流。另一个方向是把统计报表导出得更丰富比如导出PDF格式的周报月报减少管理者手工汇总的时间。还有一个值得扩展的是工时预警机制按周设置每个成员的正常工时阈值超过阈值时在仪表盘上做醒目标记。这个功能在加班文化比较重的团队里很实用数据透明之后管理者能一眼看到谁长期超负荷方便及时调整任务分配。不过预警阈值怎么定需要和团队负责人先谈清楚标准否则出现了连片预警系统反而会被冷落。最后说几句这个工作量统计系统的开发周期从需求确认到部署上线大约用了三周。实际写代码的时间并没有很长大量时间反而花在跟需求方确认统计口径、设计表结构、调整统计SQL这些前期工作上。这也是为什么我一直建议做这类系统的朋友先别急着克隆代码库而是花一个下午把下面几个问题想清楚统计的是工作量还是考勤工时怎么采集按什么层级汇总数据给谁看这几个问题明确了后端表和前端页面自然就出来了。如果你准备动手实践或者二次开发我的建议是从数据库表和统计SQL开始先把后端接口串通再搭Vue3前端页面。这个顺序能让你在遇到问题时快速定位是数据问题还是页面问题不会两头都在猜。