做工作量统计系统，说穿了就是把团队每个人每天干了啥、干了多少、花了多长时间，变成一张张能汇总、能穿透的报表。但真的动手写过的人都知道，这种系统看着简单，实际踩坑的地方一点也不少：统计口径怎么定、日期按哪个时区算、分页为什么莫名其妙失效、跨域为什么前端调不通……每一项都能让人折腾小半天。我最近用SpringBoot3配Vue3，再加上MyBatis和MySQL，完整实现了一套前后端分离的工作量统计系统，代码和业务都跑通了，这篇就把整个设计和编码过程中的经验完整写出来，希望能帮你少走弯路。
这套系统适合两类人看。一类是刚学完Java基础，准备用SpringBoot做课设或入职项目的初学者，可以直接拿这套架构当脚手架；另一类是工作中需要给团队做工时填报、任务统计，但不想用重型OA系统的开发同学，可以按这个思路快速搭一个轻量工具。全文会从数据库建模、后端Mapper编写、前端Vue3组件、再到常见坑位排查，按实操顺序讲，不绕弯子。
1. 项目定位：工作量统计系统到底要解决什么问题
1.1 先拆业务需求再做表，不然必返工
很多人在动手写工作量统计系统时，第一反应就是建一张“工作量表”，把所有字段堆进去，然后写增删改查。这个思路在demo阶段没问题，但一遇到真实业务就完蛋。为什么？因为工作量统计的核心不是“记录”，而是“口径”。
举个例子。一个研发团队要统计工作量，至少会有三种口径：一是按任务数量算，谁完成的任务多谁工作量大；二是按工时算，谁投入的时间长谁工作量大；三是按产出算，谁的成果被验收通过谁才有工作量。这三种口径背后对应的是完全不同的表设计和统计SQL。如果你上来就只建一张表，后面业务老师说“我要按项目维度看每个成员的本月工时”，你就得改表结构。
我这次做系统前，先花了一个晚上把需求拆成四个核心实体：用户、任务、工作量记录、统计视图。用户管“谁干的”，任务管“干什么”，工作量记录管“干了多少多久”，统计视图则完全由SQL动态聚合，不在数据库里存冗余字段。这么做的好处是，后续无论是按天、按周、按月统计，还是按成员、按项目、按任务类型分组，都只需要改SQL，不用加字段。
1.2 为什么技术栈选SpringBoot+Vue3+MyBatis+MySQL
技术选型这件事，成熟项目的选择往往是“稳”字当头，不是追新。SpringBoot3是目前Java后端的主流版本，内置Tomcat，起步依赖帮你省掉了大量繁琐配置，和MyBatis整合也很顺滑。Vue3用Composition API写业务逻辑，组件复用和组织代码都比Vue2来得清爽，配合Vite开发时热更新速度快得明显。MyBatis和MySQL更不用多说，一个是国内团队最熟悉的SQL持久层框架，一个是开源数据库里部署成本低、运维资料多的常青树。
有人会问，既然要做统计，为什么不用MyBatis-Plus或者JPA？我的理由很直接：工作量统计系统里，核心就是一堆GROUP BY、DATE_FORMAT、JOIN的复杂查询，MyBatis能把SQL完全掌握在自己手里，写起来、调起来、给同事review都清清楚楚。MyBatis-Plus确实方便，但它的QueryWrapper在复杂分组统计时会变成一大串链式调用，可读性反而不如XML里的原生SQL。
前端这块，我没选TypeScript，原因不是TS不好，而是这个项目如果后续要让公司里偏后端的同事维护，纯JavaScript学习成本更低，跑起来也不用额外处理类型报错。如果你自己能力强，换成TS完全没问题，框架层面无差别。
1.3 前后端分离架构带来的三个实际收益
前后端分离这个词现在听着不新鲜，但真把项目拆开做，收益是实打实的。第一，后端接口可以被多端复用。我这次只做了Web页面，但接口设计成了纯RESTful风格，后续如果要做企业微信里的H5报表，前端重新开发一套就行，后端一行不用改。
第二，开发和调试互不阻塞。前端用Vite开发服务器，通过代理把请求转发到后端，我改前端页面、后端同事改统计SQL，完全并行。对比传统的模板引擎项目，在同一个工程里改Java和HTML，经常因为静态资源缓存问题浪费大量时间。
第三，部署更灵活。后端打成一个Java包扔到服务器，前端build后由Nginx托管，两者可以部署在不同的机器上，哪边压力大就单独扩哪边。对于工作量统计这种内部系统，并发量不高，一台小服务器就能跑，但如果后面接入大部门，前后端分离的架构也对扩展更友好。
2. 数据库设计与建模：统计系统的地基
2.1 四张核心表和它们的关系
工作量统计系统不要设计太多表，真实业务里表越多，统计JOIN越复杂，性能越难把控。我最终保留了四张表：sys_user、work_task、work_record、audit_log。其中work_record是绝对核心，它记录的是“某人在某天对某任务投入了多少时间、做了什么事”。
sys_user就是用户表，字段包括id、用户名、密码、姓名、部门ID、角色。这里有一个细节：密码字段一定要存加密后的值，哪怕内部系统也不能明文。我用的是Spring Security自带的BCrypt加密工具，注册时加密，登录时校验，一行代码的事但能避免大问题。
work_task是任务表，描述一个具体的任务，字段有关联项目ID、任务名称、类型、负责人、优先级、开始时间、结束时间、状态。很多系统会把任务表和工作量记录表合并，我不太建议。因为一个任务可能由多人协作完成，也可能一个人分几天完成，任务表放任务固有属性，记录表放每天动态的执行情况，两张表各司其职，统计数据才不容易乱。
work_record作为核心表，字段包括id、用户ID、任务ID、工作日期、工作时长（DECIMAL类型，保留两位小数）、工作内容、审核状态、审核人、审核时间。还要加一个work_date字段，专门存“工作发生的日期”，和create_time区分开。因为create_time是数据创建时间，如果用户补录上周的记录，统计就不能看create_time。
audit_log用于记录管理员对工作量记录的审核动作。审核不是必须的，但如果这个系统要作为绩效参考，审核功能非常关键。没有审核，用户随意填写就能影响统计结果，最后系统会沦为摆设。
2.2 建表SQL和字段类型的关键点
下面直接给出我落地使用的建表SQL，你可以根据自己的业务调整字段。
CREATE TABLE sys_user ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT '用户ID', username VARCHAR(50) NOT NULL UNIQUE COMMENT '登录名', password VARCHAR(100) NOT NULL COMMENT 'BCrypt密码', real_name VARCHAR(50) COMMENT '真实姓名', dept_id BIGINT COMMENT '部门ID', role TINYINT DEFAULT 2 COMMENT '1管理员 2普通成员', status TINYINT DEFAULT 1 COMMENT '1启用 0禁用', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表'; CREATE TABLE work_task ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT '任务ID', task_name VARCHAR(200) NOT NULL COMMENT '任务名称', task_type VARCHAR(50) COMMENT '任务类型', owner_id BIGINT COMMENT '负责人ID', priority TINYINT DEFAULT 3 COMMENT '优先级 1高 2中 3低', status TINYINT DEFAULT 0 COMMENT '0未开始 1进行中 2已完成', start_time DATETIME COMMENT '计划开始', end_time DATETIME COMMENT '计划结束', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='任务表'; CREATE TABLE work_record ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT '记录ID', user_id BIGINT NOT NULL COMMENT '成员ID', task_id BIGINT NOT NULL COMMENT '任务ID', work_date DATE NOT NULL COMMENT '工作日期', work_hours DECIMAL(5,2) DEFAULT 0 COMMENT '工作时长', work_content VARCHAR(500) COMMENT '工作内容', status TINYINT DEFAULT 0 COMMENT '0待审核 1通过 2驳回', audit_by BIGINT COMMENT '审核人ID', audit_time DATETIME COMMENT '审核时间', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='工作量记录表';这里有几个字段设计上的经验可以重点提一下。一是所有字符集都用utf8mb4，而不是utf8。utf8在MySQL里最大只支持3字节，存emoji或者某些生僻字会报错，utf8mb4是完整的UTF-8实现，和前端传过来的JSON字符串兼容性最好。二是work_hours用DECIMAL(5,2)，不要用FLOAT或DOUBLE。浮点数在汇总求和时会有精度误差，统计出的工时可能变成17.999999这种值，显示起来很尴尬。三是work_date用DATE类型，不带时分秒，工作量按天统计时DATE_FORMAT效率更高，可读性也更好。
2.3 索引设计：统计查询提速的关键
代码能跑和跑得快，是两码事。工作量统计系统数据量小的时候，随便怎么查都很快，但一旦用上几个月，work_record表可能积累几万条记录，再不加索引，统计接口就会明显变慢。
我这次建了三个关键索引。第一个是(work_date, user_id)联合索引，服务于最常见的月度成员汇总查询——WHERE会先过滤时间范围，再按用户分组，这个索引能最大程度缩小扫描范围。第二个是(task_id)单列索引，当从任务维度穿透查询工作量明细时使用。第三个是(user_id, work_date)联合索引，用于个人工作台展示我某天填了没填、填了多少。
索引不是越多越好，尤其是这张表只需要支撑统计查询和明细插入，索引过多会导致INSERT变慢。取舍原则是：优先覆盖WHERE和GROUP BY经常一起出现的字段组合，完全独立的查询场景才考虑单独索引。我实测下来，在10万条记录的work_record表上，加了联合索引后，按月汇总的查询时间从1.2秒降到了50毫秒左右，这个优化力度比换硬件划算得多。
3. 后端SpringBoot3+MyBatis实现：接口怎么写得又快又稳
3.1 工程分层结构和统一返回体
后端工程我按标准的三层结构拆分：controller、service、mapper。controller只负责接收参数和响应结果，不做业务计算；service里放事务、权限校验和统计逻辑编排；mapper只做SQL和数据库交互。这套分层在小型系统里看起来很“重”，但好处是当统计逻辑复杂后，你不需要在一个controller方法里塞几十行代码。
所有接口的返回格式，我统一封装成了一个Result对象，格式是{code, message, data}。code为200表示成功，非200为业务异常。前端axios拦截器统一判断code，弹出message，这样前后端联调时的沟通成本很低，不会有“你返回的是数组我拿到是对象”这种混乱。
登录认证这块，我用了JWT。用户登录成功后，后端生成token返回给前端，后续请求在请求头里带Authorization。我没有引入Spring Security，因为系统只有管理员和普通成员两种角色，用一个简单的拦截器解析token、判断接口权限就够了。引入Security框架反而会把配置复杂度拉高，对这类内部项目不划算。
3.2 MyBatis Mapper接口与XML映射写法
MyBatis的使用方式上，我有自己的偏好：简单的单表CRUD用注解解决，涉及多表JOIN和动态SQL的统计操作全部写在XML文件里。这样既能快速开发，又能保证复杂SQL的可维护性和格式高亮，在IDEA里看XML比看一长串注解字符串舒服多了。
举个实际例子，工作量记录的分页查询。前端表格需要按成员姓名、时间范围、状态筛选，还要关联显示任务名称，这个操作必须走XML：
<mapper namespace="com.example.mapper.WorkRecordMapper"> <select id="selectRecordPage" resultType="com.example.entity.dto.WorkRecordDTO"> SELECT r.id, u.real_name AS realName, t.task_name AS taskName, r.work_date AS workDate, r.work_hours AS workHours, r.work_content AS workContent, r.status, r.create_time AS createTime FROM work_record r LEFT JOIN sys_user u ON r.user_id = u.id LEFT JOIN work_task t ON r.task_id = t.id <where> <if test="query.realName != null and query.realName != ''"> AND u.real_name LIKE CONCAT('%', #{query.realName}, '%') </if> <if test="query.startDate != null"> AND r.work_date >= #{query.startDate} </if> <if test="query.endDate != null"> AND r.work_date <= #{query.endDate} </if> <if test="query.status != null"> AND r.status = #{query.status} </if> </where> ORDER BY r.work_date DESC, r.create_time DESC </select> </mapper>这段XML有两点要注意。第一，时间筛选用的是r.work_date而不是r.create_time，这是之前反复强调的口径问题。第二，XML中小于号必须写成>=，因为XML解析器不允许裸的<字符，写成">="或">="会报Mapped Statements collection错误，这个坑新人经常遇到。
3.3 分页插件PageHelper的使用姿势和易错点
分页插件是MyBatis生态里最常用的增强工具，核心原理是通过MyBatis拦截器拦截Executor，在SQL执行前自动拼接LIMIT语句。用法看起来简单，但很多人在真实项目里用错。
正确姿势是这样的：在Service层调用Mapper查询之前，必须先调用PageHelper.startPage(pageNum, pageSize)，然后紧接着执行Mapper查询。注意是“紧接着”，中间不能有任何其他数据库操作，否则分页会作用到别的查询上。
public PageResult<WorkRecordDTO> pageRecords(WorkRecordQuery query) { PageHelper.startPage(query.getPageNum(), query.getPageSize()); List<WorkRecordDTO> list = workRecordMapper.selectRecordPage(query); PageInfo<WorkRecordDTO> pageInfo = new PageInfo<>(list); return PageResult.of(pageInfo); }我这里把PageHelper.startPage放在Service层，而不是Controller层，原因是为了隔离职责。Controller只负责接收前端参数，Service负责业务逻辑，分页属于业务的一部分，放Service层再合适不过。
还有一个细节：startPage返回的Page对象其实是一个ArrayList子类，MyBatis查询后返回的list就是Page类型，可以直接拿到total数据。但如果你在Mapper里返回的resultType是Map，或者执行的是自定义返回对象，一样可以用PageInfo包装，它会自动从Page对象里读取总数、页数。
3.4 核心工作量统计SQL：按成员/时间维度聚合
工作量统计系统的灵魂，是最后那张带分组聚合的报表。我实现了两个维度的统计：一个按成员聚合，看每人某月完成多少个任务、累计多少工时；另一个按项目或者任务类型聚合，看工作量的分布情况。
按成员月度聚合的SQL如下：
SELECT u.real_name AS realName, DATE_FORMAT(r.work_date, '%Y-%m') AS statMonth, COUNT(DISTINCT r.task_id) AS taskCount, ROUND(SUM(r.work_hours), 2) AS totalHours FROM work_record r LEFT JOIN sys_user u ON r.user_id = u.id WHERE r.work_date BETWEEN #{startDate} AND #{endDate} AND r.status = 1 GROUP BY u.real_name, DATE_FORMAT(r.work_date, '%Y-%m') ORDER BY totalHours DESC这段SQL有几个关键点。DATE_FORMAT(r.work_date, '%Y-%m')可以把DATE类型格式化成“2025-03”这种月份字符串，这是报表端横轴纵轴最需要的格式。COUNT(DISTINCT r.task_id)统计的是任务数量，不是记录数量，否则一个人同一天干了三个任务，会被算成三次。ROUND(SUM(r.work_hours), 2)保证最终汇总结果只有两位小数，避免前端展示出现一长串小数位。
我用LEFT JOIN而不是INNER JOIN，是因为统计报表要保证不遗漏任何用户。即使某个成员当月没有工作量记录，也要在报表里露出他的名字，只是数值为0。如果换成INNER JOIN，没填记录的人会直接从报表里消失，这在管理视角上是非常不友好的。
4. 前端Vue3落地：从初始化到图表展示
4.1 Vite初始化项目和目录组织
前端我选择了Vite作为构建工具。相比Webpack，Vite在开发模式下利用ESModule原生按需加载，冷启动速度和热更新都明显更快。初始化命令一行搞定：
npm create vite@latest work-stat-web -- --template vue创建完成后，进入项目安装依赖。这里我建议把axios、element-plus、pinia、echarts一次装齐，避免后续反复装包浪费时间。在package.json里把依赖分开看，dependencies管运行时依赖，devDependencies管构建工具链，Vite相关插件不需要打进生产包。
目录组织上，我按vue项目的常见约定划分：src/api放接口定义，src/router放路由，src/stores放Pinia状态，src/views放页面组件。每新增一个页面，先在views里建文件，再在router里注册路由，接口则统一在api目录下定义一个模块文件。这个约定看起来死板，但多人协作或者自己隔一个月回来看代码，找东西完全不用猜。
4.2 Axios封装和Pinia状态管理
axios不能直接裸用，一定要封装。我在src/api/http.js里创建了一个axios实例，设置了baseURL为/api，timeout为10秒，然后在请求拦截器里从Pinia中读取token并放到Authorization头里。响应拦截器里统一处理业务状态码，code不是200时用ElMessage弹窗提示，401时清空用户信息跳回登录页。
import axios from 'axios' import { ElMessage } from 'element-plus' import { useUserStore } from '../stores/user' const service = axios.create({ baseURL: '/api', timeout: 10000 }) service.interceptors.request.use(config => { const userStore = useUserStore() if (userStore.token) { config.headers.Authorization = `Bearer ${userStore.token}` } return config }) service.interceptors.response.use(response => { const res = response.data if (res.code === 200) return res if (res.code === 401) { useUserStore().logout() window.location.href = '/login' } ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) }, error => { ElMessage.error(error.message || '网络异常') return Promise.reject(error) }) export default servicePinia用来管理全局状态。像token、当前登录用户信息、部门列表这种被多处组件共享且需要响应式的数据，必须放Pinia。不要先在每个组件里单独localStorage读写，后面同步状态会非常痛苦。我这个项目里建了userStore和workStore，userStore管登录态，workStore缓存统计条件和查询结果，切换页面时不用重新请求。
4.3 Element Plus表格和ECharts图表实现
统计系统的前端，本质上就是两个东西：可筛选的明细表格和可下钻的聚合图表。明细页我用了Element Plus的el-table，配合el-date-picker选择日期范围、el-select选成员。
表格列渲染上，有一个细节值得提：工作时长的展示。数据库存的是DECIMAL，后端返回可能是17.50，但el-table默认会原样显示。如果你想保留两位小数，可以用formatter统一处理，比如row.workHours ? Number(row.workHours).toFixed(2) : '0.00'。这个处理看起来小，但报表页面小数位忽长忽短，会给使用者一种“数据很随意”的感觉，影响信任度。
图表部分，我用ECharts实现成员月度工时柱状图和任务类型占比饼图。ECharts和Vue3配合有两种方式：一种是直接在后端返回统计明细后，前端手动setOption；另一种是封装一个chart组件，通过props传数据。我推荐后者，因为图表组件在同一页面里可能会复用多次，封装后只需要传data和type两个prop，内部自己处理option拼接、resize监听、实例销毁。
import * as echarts from 'echarts' import { onMounted, onBeforeUnmount, ref, watch } from 'vue' const chartRef = ref(null) let chartInstance = null onMounted(() => { chartInstance = echarts.init(chartRef.value) }) watch(() => props.data, () => { if (!chartInstance) return chartInstance.setOption(buildOption(props.data, props.type)) }, { deep: true }) onBeforeUnmount(() => { chartInstance && chartInstance.dispose() })这个封装最核心的坑在chartInstance.dispose()。如果你不监听组件卸载销毁实例，页面切换时ECharts会报一个“There is a chart instance already initialized on the dom”的警告，背景是canvas重复初始化导致内存泄漏。我见过不少项目在前端控制台狂刷这个警告，其实加一句onBeforeUnmount就解决了。
5. 实战中必踩的五个坑和排查方法
5.1 分页插件不生效，list没有被截断
这个现象是：前端传了pageNum和pageSize，但接口返回的list长度始终是全部数据。排查思路要按顺序走。
先确认PageHelper.startPage方法确实被调用了，且紧跟在Mapper查询之前。如果startPage所在的方法在Service层，而Mapper查询在另一个方法里通过Spring代理调用，分页会失效。再检查MyBatis配置的拦截器是否注册成功，没有加pagehelper依赖或配置的话，startPage被调用也不会生效。最后检查是不是多数据源场景，如果配置了多个SqlSessionFactory，需要在每个工厂上都加拦截器。注意startPage只对紧接着的一条查询生效，一次请求里如果先后调用了两次Mapper查询，第二次会把第一次的分页参数覆盖掉。
5.2 前端调接口报跨域，后端配置了还是不行
前后端分离后，Vite开发服务器跑在5173，后端跑在8080，端口不同必然触发跨域。解决方式有两种：后端加CORS配置，或者前端用Vite代理。
我推荐前端代理，因为生产环境Nginx反代同样需要配置转发，开发环境用代理更符合最终部署形态。在vite.config.js里这样配置：
server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, rewrite: path => path.replace(/^\/api/, '') } } }如果你确实要在后端开CORS，注意SpringBoot3中有个容易踩的坑——CorsFilter的addAllowedOrigin方法如果你写成config.addAllowedOrigin("*")，有些浏览器在携带Authorization头时会被拒绝。需要调用config.addAllowedOrigin("*")配合config.addAllowedHeader("*")一起，并且不要设置allowCredentials为true，两者混用是浏览器规范里明确禁止的。
5.3 统计报表日期差8小时，数据看起来对不上
这个问题很经典。我在联调月度统计接口时发现，数据库里明明有某条3月10日的记录，报表里却显示在3月9日，或者统计柱状图错位。原因通常在于MySQL连接串里的时区参数没配好。
JDBC连接串上务必加上serverTimezone=Asia/Shanghai，否则MySQL驱动会使用服务器默认时区，如果你本机是UTC或者是别的时区，DATE字段在驱动处理时会受时区偏移影响。同时后端Jackson序列化Date类型时也要指定时区：在application.yml中配置spring.jackson.time-zone: GMT+8。这两个配置配合好，前端拿到的日期格式就不会出现差8小时的问题。
5.4 我填了记录但汇总里没统计到
用户填了工作量记录，管理员看汇总却没有数据，这个问题的头号嫌疑是状态过滤。我的逻辑是只统计status=1（已通过）的记录，待审核状态不被纳入汇总。所以如果业务上希望用户刚提交就能看到效果，要么默认状态置为1，要么在报表中增加“含待审核”的口径选项。开发时建议给这个筛选条件加一个醒目的选项标签，否则容易产生“系统丢数据”的误判，这是产品层面最容易忽略的问题。
5.5 Excel导出中文乱码
工作量统计系统往往需要导出Excel交到人事或财务，这里也有一个常见坑：直接用URL直接拼接文件名，比如response.setHeader("Content-Disposition", "attachment;filename=" + filename)，中文文件名在浏览器里会变成一堆百分号编码。正确的做法是将文件名转成RFC 5987格式，即filename*=UTF-8''+ URLEncoder.encode(filename, "UTF-8")，这样导出时中文文件名才能正常显示。这个坑我第一次做导出功能时踩过，后来整理成公司内部文档，后来的人复制粘贴就能避免。
写在最后的个人体会
整个项目从零到跑通，我最大的感受是：做这类管理统计系统，技术本身不是瓶颈，而是业务口径和数据边界要花时间理清。SpringBoot、Vue3、MyBatis、MySQL这一套组合，单看每一个都不难，难的是把它们组织在一起还能让后续维护者看懂你的逻辑。如果你正打算做类似系统，我建议你先拿半天时间画清楚ER图，把“统计什么、按什么口径统计、谁有权限看统计结果”这三个问题想明白了再写代码，比直接上手搭框架效率高得多。
最后再分享一个我测试时的小技巧：在work_record表里插入一批随机测试数据时，直接用MySQL的递归CTE批量生成即可，不需要逐条insert。比如用WITH RECURSIVE生成近半年的日期序列，再配合RAND()生成随机工时，一条SQL就能造出几千条数据，验证分页和汇总性能非常方便。这套系统我已经跑通了核心链路，后续如果要接入更多维度的报表，架构上也不用推翻重来，改改统计SQL、加个前端页面就能扩展。
