SpringBoot+Vue+MyBatis企业工作量统计系统完整源码拆解

这些年接的企业内部管理系统不少但真正能在“工作量统计”这件事上做明白的其实不多。年前交付的一套企业级工作量统计系统源码完整放了出来用的是SpringBoot Vue MyBatis MySQL这套经典组合。这套系统本质上回答了一个很实际的问题一个团队几十上百号人每天每个人到底在忙什么忙了多少哪些事情占用了核心人力月末考核的时候怎么拿出让人信服的数据。如果你正在做类似的绩效统计、工时管理、项目台账类系统这篇拆解值得认真看完。1. 项目定位与整体设计思路1.1 这套系统到底解决了什么问题很多公司考勤有打卡财务有报销但“工作量”一直是个模糊地带。项目排期拍脑袋绩效打分凭印象管理者问“上周你们组干了多少活”组长只能说“大概做了几个需求”。这套工作量统计系统要解决的核心矛盾就是把“干活”这件事数据化、可量化、可追溯。系统的核心业务模型其实不复杂每个员工通过录入工作项来记录自己的产出工作项关联到具体项目、任务类型、工时消耗管理者按月按周按项目维度去聚合统计最终形成个人工作量报表、项目投入报表、部门负荷报表。数据落地之后绩效考核、人员调度、成本核算就都有了依据。源码的完整度主要体现在几个地方一是权限体系完整管理员、部门主管、普通员工三层角色数据可见范围是隔离的二是统计口径支持按天、按周、按月、按项目、按任务类型多维度切换三是工作项支持审核流员工提交的数据经过主管确认后才会进入统计口径避免乱报工时的情况四是前端有可视化报表ECharts柱状图、折线图、饼图直接展示管理层不需要看表格也能一眼看懂团队负荷。1.2 技术选型为什么还是这套经典组合这套系统虽然是“老组合”但从企业交付的角度来说它仍然是最稳妥的选型。SpringBoot的价值在于开箱即用。企业项目最怕的是环境折腾一星期、配置写了八百行。Spring Boot的自动配置把数据源、事务、Web MVC这套东西都预置好了一个main方法启动整个应用交付的时候打成jar包扔服务器上就能跑这对做企业内网部署太重要了。再加上它的生态成熟Spring Security做权限、Redis做缓存、定时任务做统计预聚合后面要扩展几乎不需要换框架。Vue在前端领域的地位不用多说上手门槛低组件化开发效率高配合Element UI做后台管理界面是绝配。工作量统计系统这种典型的中后台应用信息密度大、表单多、表格多、筛选条件多Vue的双向绑定和组件复用能把这类页面的开发成本压得很低。MyBatis在这套系统里是刻意的选择而不是妥协。工作量统计的核心逻辑在数据库聚合查询MyBatis最擅长的就是让你把SQL攥在自己手里。统计报表里那些多表JOIN、GROUP BY、CASE WHEN嵌套的复杂SQL如果用JPA写你会疯掉但用MyBatis你可以在XML里精雕细琢还能让DBA直接review SQL做优化。另外项目里大量使用了动态SQL多条件组合查询、批量插入、批量更新MyBatis的if、foreach标签在可读性和灵活性上都是最优解。MySQL的选型没什么好说的这个量级的工作量数据用MySQL完全够用单表几千万行之内通过合理的索引和分页策略都能扛住而且运维成本低企业内部找一个会MySQL的人比找一个会Oracle的人容易太多。1.3 功能模块的划分与边界整套系统按业务边界拆成了七个模块模块之间通过Spring的IOC解耦代码结构上用的是标准的Controller-Service-Mapper三层系统管理用户管理、部门管理、角色权限、菜单管理、操作日志项目管理项目信息维护、项目成员绑定、项目状态流转工作项管理工作项填报、工作项审核、工作项驳回、工作项修改统计报表个人维度统计、项目维度统计、部门维度统计、月度趋势分析消息通知审核结果通知、系统公告、待办提醒基础配置任务类型字典、工作量权重配置、统计口径配置数据导出报表Excel导出、工作项明细导出模块边界的核心原则是业务闭环从项目创建到员工填报到主管审核到统计展示到数据导出一条链走通中间没有断点。很多工作量统计系统最后用不起来就是因为某一个环节断了比如数据只录不审导致报表里全是水分。2. 数据库设计与核心数据模型2.1 核心表结构是怎么设计的工作量统计系统的表结构设计决定了后续统计SQL的复杂程度。这套系统一共设计了19张表其中最核心的是下面这几张用户表sys_user和部门表sys_dept不展开说标准RBAC模型的常见设计。关键在work_order工作项表这是业务主表记录了每一条工作量数据的原始凭证。字段设计上有几个关键点owner_id归属人、project_id关联项目、work_type任务类型、work_date工作日期、work_hours工时、audit_status审核状态、audit_by审核人、audit_time审核时间。特别注意设计了work_load字段工作量积分它的值等于work_hours乘以任务类型的权重系数比如“简单咨询”权重是0.8“核心开发”权重是1.5月底统计其实是按这个积分的总和来算的这样“同样干8小时干的活含金量不一样”的问题就从数据层面解决了。工作量明细表work_detail有几张按日、周、月做了三级预聚合这个下面单独说。权限相关用标准的五表模型用户表、角色表、菜单表、用户角色关联表、角色菜单关联表没有过度设计。2.2 统计结果的预聚合设计这是整套系统里我觉得最有价值的设计。最初版本没有预聚合表报表查询直接在主表上GROUP BY数据量上来之后大约10万条就明显变慢一条月度汇总SQL跑两秒多前端交互卡得难受。后来改成了预聚合方案用定时任务在每天晚上把当天的数据按“人日”粒度汇总到work_daily_summary表再按“人月”粒度汇总到work_monthly_summary表。报表查询时优先读聚合表只有需要下钻到明细时才查work_order主表。这样设计之后同样的报表接口响应时间从两秒降到了两百毫秒以内体验是完全不一样的。聚合表结构上比主表多了一个unique key如(owner_id, work_date)配合INSERT ... ON DUPLICATE KEY UPDATE实现幂等写入定时任务即使重复执行也不会产生脏数据。2.3 索引设计里的门道索引这个东西面试题里一大把但真正在做工作量统计这种读多写少、统计条件固定的系统时设计重点是很不一样的。work_order表上最核心的索引是联合索引(owner_id, work_date, audit_status)因为绝大多数统计SQL的WHERE条件都是这三个字段的组合。注意联合索引的字段顺序区分度高的放前面owner_id的区分度最高所以放第一位。另外project_id单独建索引因为按项目维度的跨人统计经常会用到不需要让MySQL走全表扫描。work_monthly_summary表上建的是(owner_id, stat_month)联合唯一索引避免同一人同一个月产生重复汇总行。work_daily_summary同理也是(owner_id, work_date)。这里有个经验不要迷信“索引越多越好”。每多一个索引写入的时候就要多维护一棵B树。工作项录入是高频操作如果为了提高某种极低频率查询的性能去大量加索引反而会拖慢主流程。这套系统上线两个月后做了一次索引瘦身删掉了3个冗余索引写入性能提升了15%左右。3. 后端实现SpringBoot MyBatis 从骨架到核心逻辑3.1 项目骨架与关键配置项源码是基于SpringBoot 2.3.x做的JDK用的1.8没有用太新的版本原因有两条一是企业内部服务器很多还停留在JDK8环境用新版本反而会引入部署兼容性问题二是SpringBoot 2.3.x这套依赖体系非常成熟网上遇到的问题解决方案一搜一大把团队协作时排障效率高。application.yml里几个关键配置值得单独拿出来说spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/workload_stat?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.enterprise.workload.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpldatasource这里要特别注意serverTimezone参数MySQL 8.x的驱动强制要求指定时区不写的话启动直接报错。之前接过一个二手项目就是因为漏了这个配置踩坑。HikariCP连接池的maximum-pool-size默认值是10这种统计系统并发量不大20完全够用但连接池太小的话遇到报表导出这种长时间的查询连接会被拿光其他请求全部阻塞。minimum-idle留5个保底连接避免请求来了再临时建连接。MyBatis的map-underscore-to-camel-case这个配置强烈建议打开否则数据库的work_hours字段映射到Java的workHours属性全是null排查起来非常痛苦。3.2 动态SQL的实战写法工作量统计的查询条件组合太多了按时间范围、按部门、按项目、按任务类型、按审核状态每一种组合都可能出现。这种情况用动态SQL是唯一合理的选择。MyBatis在这个场景下的价值体现得特别充分举一个实际例子select idselectWorkOrderPage resultTypecom.enterprise.workload.entity.WorkOrder SELECT wo.*, u.real_name, p.project_name FROM work_order wo LEFT JOIN sys_user u ON wo.owner_id u.id LEFT JOIN project p ON wo.project_id p.id where if testownerId ! null and ownerId ! AND wo.owner_id #{ownerId} /if if testdeptId ! null and deptId ! AND u.dept_id #{deptId} /if if testprojectId ! null and projectId ! AND wo.project_id #{projectId} /if if testworkType ! null and workType ! AND wo.work_type #{workType} /if if testauditStatus ! null AND wo.audit_status #{auditStatus} /if if teststartDate ! null AND wo.work_date gt; #{startDate} /if if testendDate ! null AND wo.work_date lt; #{endDate} /if /where ORDER BY wo.create_time DESC /select两个细节说一下。第一和是XML里转义后的大于号和小于号不转义XML直接解析报错这是MyBatis新手最常见的坑。第二where标签通过JDK反射机制扫描test属性空串和null都能自动过滤掉多余的AND比手动写WHERE 11这种方式干净得多。批量插入工作项明细的时候用foreachinsert idbatchInsert parameterTypelist INSERT INTO work_detail ( order_id, work_date, work_hours, description, create_time ) VALUES foreach collectionlist itemitem separator, (#{item.orderId}, #{item.workDate}, #{item.workHours}, #{item.description}, NOW()) /foreach /insert注意MySQL单条INSERT语句的默认max_allowed_packet是4MB如果一次批量插入的条数特别大比如超过500条包大小可能会超限建议在Service层做分批处理每批200条左右比较稳妥。3.3 工作量聚合统计的SQL怎么写出彩这套系统里最能体现MyBatis价值的就是统计报表那几条SQL。月度工作量统计的核心SQL长这样SELECT u.real_name, d.dept_name, COUNT(DISTINCT wo.id) AS work_count, SUM(wo.work_hours) AS total_hours, SUM(wo.work_load) AS total_load, AVG(wo.work_hours) AS avg_hours_per_item, SUM(CASE WHEN wo.work_type DEV THEN wo.work_load ELSE 0 END) AS dev_load, SUM(CASE WHEN wo.work_type TEST THEN wo.work_load ELSE 0 END) AS test_load, SUM(CASE WHEN wo.work_type DOC THEN wo.work_load ELSE 0 END) AS doc_load FROM work_order wo INNER JOIN sys_user u ON wo.owner_id u.id INNER JOIN sys_dept d ON u.dept_id d.id WHERE wo.work_date BETWEEN #{startDate} AND #{endDate} AND wo.audit_status 1 GROUP BY wo.owner_id, u.real_name, d.dept_name ORDER BY total_load DESC这条SQL里最需要注意的是COUNT(DISTINCT wo.id)去重是为了保证一条工作项不会被重复计数。实际开发中遇到过一个问题工作项有多次修改记录存到日志表如果不做DISTINCT联表之后统计出的数量就翻倍了。再有就是SUM(CASE WHEN ...)这种写法很有用可以一次性算出不同任务类型的工作量占比不用查多次再在Java里做聚合。前端饼图的数据来源就是这条SQL的结果按DEV、TEST、DOC三类任务的load分别统计一眼就能看出团队的核心精力分配在哪类事情上。分页这块用的是PageHelper插件这是MyBatis生态里最常用也是坑最多的分页方案。用法很简单查询前调用PageHelper.startPage(pageNum, pageSize)紧接着的Mapper查询会自动拦截并加上LIMIT。但这里有个重要的使用禁忌startPage只对紧随其后的第一条SQL生效如果你在startPage和Mapper查询之间插了其他查询比如查了部门列表分页就会失效。另外PageHelper在统计COUNT时会自动生成一条count查询如果你的主SQL里有GROUP BYcount语句的执行逻辑可能会出现误差这种场景建议用PageHelper的countSql参数指定手动编写的count SQL。3.4 事务与并发控制避免工作量数据错乱工作项录入和审核都涉及事务这块设计不好会出大问题。典型的场景员工提交一条工作项主管在审核的同时员工想改这条工作项。如果两个操作并发执行很容易出现更新丢失。方案是在审核接口上加上乐观锁UPDATE work_order SET audit_status #{targetStatus}, audit_by #{auditBy}, audit_time NOW() WHERE id #{id} AND audit_status #{expectStatus}先查出来当前状态更新时在WHERE里带上期望状态受影响行数为0就说明数据已经被别人改过此时抛异常并让前端提示刷新重试。这种方案比SELECT FOR UPDATE的悲观锁轻量很多而且不会死锁适合这种并发量不高的场景。工作项提交时的数据校验也很重要。员工填工时的时候前端可能限制工时不能超过24小时但永远不要信任前端传上来的数据。后端Controller入参校验用Validated注解配合JSR-303的NotNull、Max等注解一个校验注解就能挡住脏数据。比如work_hours的校验规则是0.5到16小时之间超过这个范围的输入直接拒绝从源头保证统计数据是合理的。3.5 权限控制的落地从注解到拦截器企业系统的权限控制和互联网应用不一样互联网应用只要区分用户和管理员两种角色就够了但企业内部系统普通员工不能看别人的工资部门主管只能看本部门数据管理员什么都能看。这套系统用Spring Security做认证在登录成功之后把用户信息存到SecurityContext里接口层面通过自定义注解RequirePermission来控制访问权限RequirePermission({admin, dept_manager}) GetMapping(/report/monthly) public Result getMonthlyReport(RequestParam String month) { // ... }切面里拿到当前用户的角色列表和注解要求的角色做交集没有交集就返回403。这种实现方式比Spring Security原生的PreAuthorize更直观因为可以直接在注解里定义企业内部自定义的角色编码不需要写复杂SpEL表达式。数据级别的权限比如部门主管只能查询本部门成员的工作量通过AOP在SQL层自动拼接dept_id过滤条件实现这样Service层的代码就不需要每个方法都手动去判断数据权限而是框架统一处理既省事又不容易漏。新版Vue3.4的defineModel、Pinia这些特性确实很好用但如果你项目里的Vue版本还停留在2.x也不影响这套系统的落地——工作量统计这种中后台系统不追求花哨交互追求的是稳定高效。4. 前端实现Vue 工作台与报表可视化4.1 Vue项目的初始化与请求封装前端是基于Vue2 Element UI ECharts这套组合Vue CLI创建的项目。为什么用Vue2而不是Vue3核心原因是Element UI当前对Vue3的兼容是通过Element Plus来做的而Element Plus在早期版本里存在一些组件稳定性问题这套源码交付的时候Element Plus还不够成熟。如果你是个人学习或者全新项目直接上Vue3是没问题的但如果是企业交付求稳的话Vue2生态的系统在2020-2023年间依然是主流选择。源码的注释里也标明了升级Vue3的路径后面自己做二次开发可以平滑迁移。前端项目结构按业务模块划分了views目录工作项管理相关的页面有work-order-list工作项列表、work-order-edit工作项填报、work-order-audit工作项审核统计报表相关的有report-personal个人统计、report-project项目统计、report-department部门统计、trend-analysis趋势分析。请求封装这块用的是axios实例化创建时统一配置baseURL和超时时间。开发环境通过vue.config.js里的devServer.proxy做代理转发把/api前缀的请求转发到后端的localhost:8080这样规避了开发时跨域问题。上线环境则是后端配置CorsFilter允许指定域名跨域访问这个后面部署章节会细说。axios拦截器是必须做的。请求拦截器里从localStorage取出token放到Authorization头里响应拦截器里统一处理后端返回的code字段code为401时说明登录过期直接跳转登录页code为500时弹出错误消息。这些逻辑如果每个页面都重复写一遍代码就失控了。统一封装之后业务代码里只需要关注正常返回的数据结构异常情况由拦截器兜住一个月下游维护成本就省一大截。4.2 工作项填报与审核流程的前端交互工作量填报页面是整个系统使用频率最高的页面交互设计直接影响用户体验。这里有几个细节做得好日期选择器默认值是今天减少操作步骤。工时输入框做了步进限制按0.5小时为单位调整既保留了填报的灵活性又防止出现0.3小时这种不好统计的碎片值。任务类型下拉框选项从后端字典接口动态加载这样以后要加类型不用改前端代码改数据库字典表就行。审核页面是典型的列表详情抽屉模式。主管进入审核页看到的是待审核的工作项列表点击“查看”弹出右侧Drawer展示这条工作项的详细信息包括填写的描述、工时、关联项目。页面上有“通过”和“驳回”两个按钮驳回时强制要求填写驳回原因这个原因会通过消息通知推送给员工让他知道哪里填得不对。列表上还做了批量审核功能勾选多条同类工作项可以一键全部通过避免主管每天在审核上花太多时间。4.3 统计报表的可视化呈现报表模块是这套系统的高光部分。个人工作量报表页面顶部是汇总指标卡展示本月累计工时、累计工作量积分、已完成工作项数这个卡片数据来自后端聚合接口在页面加载时一次性返回不用多次请求。指标卡下方是ECharts的堆叠柱状图横轴是日期纵轴是工时每个日期下按任务类型堆叠了不同颜色的柱子可以一眼看出每天的时间都花在了哪里。项目投入报表用的是饼图加表格的布局。饼图展示这个项目里各成员的工作量占比表格展示成员的明细数据。饼图的legend和tooltip都是默认配置数据量不大时完全不卡。月度趋势分析页面用折线图展示近6个月的部门总工作量变化趋势叠加了平均值参考线方便管理者对比当前月份是否在正常范围内。ECharts的体验优化方面有一点值得说图表组件在Vue中的初始化和销毁一定要在mounted和beforeDestroy生命周期钩子里处理否则切换路由时会报“Initialize failed: invalid dom”的错误。另外窗口尺寸变化时调用chart.resize()这个可以用一个监听window resize事件的全局指令来做但注意要防抖否则页面缩放时会频繁触发重绘导致卡顿。4.4 路由守卫与权限菜单的动态渲染前端权限控制用的是典型的动态路由方案。用户登录成功后后端返回该用户有权访问的菜单列表前端根据这个列表动态注册路由。axios拦截器在登录时只写token路由守卫里做的事情是判断token是否存在没有token直接去登录页有token但Store里没有用户菜单信息就调接口拉取菜单再动态添加路由然后放行。菜单渲染用Vue Router的addRoutes方法在全局路由守卫的next()回调前注册完成。这里有个注意点addRoutes是异步生效的第一次进入系统时如果URL是动态路由里的路径比如直接刷新“/report/project”会出现暂时匹配不到路由导致404的问题。解决方案是在路由守卫里做一个标记ADMIN_FLAGtrue时放行一次让路由同步完成否则在beforeEach里死循环。这是个很典型的Vue权限实现中的陷阱源码里已经处理好了你直接跑demo不会遇到这个问题但如果自己从零写会有这段弯路。5. 部署方案与性能优化实践5.1 构建打包与服务器部署这套系统的部署方式比较朴素SpringBoot打jar包直接跑前端build之后把静态文件复制到SpringBoot的static目录下一个进程同时提供前后端服务。这种方案的好处是部署成本极低不用单独配Nginx适合服务器资源有限的中小企业。当然如果并发上来了前后端分离部署更合理前端静态文件扔Nginx后端jar包独立跑再加一层反向代理搞定跨域。源码里两种方式都写了启动脚本。部署的关键步骤后端执行mvn clean package -DskipTests在target目录生成可执行jar包前端执行npm run build把dist目录里的文件复制到src/main/resources/static下上传jar包到服务器执行java -jar workload-system.jar --spring.profiles.activeprod初始化数据库执行sql/init.sql创建库表结构并插入初始化数据记得用nohup后台启动并配合systemd管理进程这样服务器重启后系统能自动拉起来5.2 性能优化三板斧这套系统上线之后做了几轮性能优化核心思路是“能查聚合表不查明细表能走索引不走全表能缓存就不查库”。第一统计报表的查询全部改成走预聚合表这是收益最大的一步优化。月度报表下钻到个人明细时才去查work_order主表。第二热门接口加了Redis缓存。比如首页的部门工作量汇总卡片数据每天凌晨定时刷新一次缓存过期时间设为24小时接口QPS再高也打不到数据库。第三慢SQL日志打开后定期从慢日志里捞出来分析发现大部分慢查询都卡在work_order表的work_date字段上后续在这个字段上补了单列索引查询速度从700ms降到了30ms。数据库连接池、线程池的参数也做了调优。HikariCP最大连接数从10调到20Tomcat的max-threads从200调到500。这些参数不是越大越好要根据服务器的CPU核数和内存大小来配2核4G的服务器把连接池调到50反而是负担。6. 常见问题与排查清单6.1 高频问题速查表根据源码交付后用户反馈和开发过程中的实际踩坑整理了一份高频问题速查表问题现象可能原因排查与解决方式登录后接口返回401token过期或拦截器把放行路径拦截了检查请求头是否带上了Authorization检查SecurityConfig/拦截器中path的放行列表登录接口和静态资源必须放行PageHelper分页不生效startPage和Mapper查询之间夹了其他数据库操作确保startPage紧跟在目标查询的上一行多条SQL时考虑用PageInfo的setPageNum手动指定页报表接口查询很慢没有走预聚合表或索引失效用EXPLAIN看执行计划确认是否走了work_monthly_summary聚合表检查WHERE条件字段类型是否一致前端请求跨域报错后端未配置CorsFilter或代理没生效开发环境走vue.config.js代理生产环境后端加CorsFilter或交给Nginx转发数据库导入中文乱码SQL文件编码和数据库字符集不一致统一使用UTF-8编码保存SQL文件数据库连接URL加characterEncodingutf8定时统计没有执行定时任务开关未开启或SpringBootApplication中没加EnableScheduling检查启动类注解检查任务日志输出工作项提交后统计不到数据审核状态不是已通过统计SQL默认只统计audit_status1确认数据已通过审核检查统计SQL的state条件是否匹配6.2 源码二次开发时的几个注意点如果你拿到源码准备做二次开发有几点经验可以先告诉你。扩展工作量维度时改work_type的字段值是不够的要去sys_dict字典表里维护新的类型编码同时把work_load_weight权重表里对应类型的系数配上这样新增类型就会自动参与统计前端下拉框也不用改。如果要做新的统计报表优先在work_daily_summary和work_monthly_summary上做不要直接改work_order的SQL保持预聚合层的稳定性。修改定时任务执行时间时直接改cron表达式就行但要注意任务幂等性也就是说同一天数据被重跑两次结果不能翻倍聚合表的唯一索引和ON DUPLICATE KEY UPDATE已经把这一步处理好了。前端二次开发时新增页面组件记得在路由表里注册并添加对应的菜单数据。如果使用了动态路由后端菜单表里也要配置才能真正访问。6.3 上线前容易被忽视的检查项上线前一天你可以按这个清单逐一过一遍数据库备份脚本是否配置好work_order这种业务主表的备份策略要明确至少每天凌晨全量备份定时任务的日志是否输出到文件避免出问题闭着眼找日志服务器时区是否正确。MySQL连接URL里已经指定了serverTimezoneAsia/Shanghai但要确认服务器系统时区也是Asia/Shanghai否则时间字段的存储和展示会出现8小时偏差Redis连接池、线程池参数在服务器上重新跑一遍压测压测工具用JMeter即可模拟50个并发用户连续操作10分钟观察接口响应时间和内存占用是否在安全范围默认密码是否已经修改。admin用户的初始密码要强制改掉上线后第一件事就是这个这些坑都是我实际踩过的。页面上看着一切正常但进了报表统计发现数字对不上一查是时区差了8小时数据库里记录的work_date是前一天这种问题不排查到那个层面根本发现不了。这套系统的完整源码覆盖了从需求设计到部署上线的全链路核心代码、初始化SQL、部署文档、README一应俱全。如果你正打算做类似的工作量统计或工时管理系统直接拿来改一改就能用省去从零搭建的重复劳动把精力放在业务定制上会更高效。第一次部署、第一次统计出报表、第一次审出一条工作项每一个环节的真实数据都是这套系统价值的最好证明。