基于SpringBoot+Vue的工作量统计系统设计与前后端分离部署实践

前阵子接了个内部需求：某部门要做一套工作量统计系统，用来代替月底手工汇总Excel表格的方式。这个系统说大不大，说小也不小——多人填报、多角色查看、按项目按月出报表，还要能导出存档。我直接用前后端分离的方案来落地：后端SpringBoot+MyBatis+MySQL，前端Vue，两边独立开发独立部署。整套做完再回看，工作量统计这类系统非常适合作为全栈练手项目，也适合直接改一改塞进公司内部工具里。这篇文章我把完整的设计思路、核心代码、部署过程、以及测试阶段踩过的坑都整理出来，想自己动手做一个类似系统的话，照着走基本能复现。

先说下这套系统能干什么。登录后普通成员可以填报每天的工作内容和工作时长，部门负责人可以审核、查看团队维度的日报月报，管理员负责维护成员账号和项目信息。数据全程线上流转，月末再也不用找每个人要Excel了。统计报表按人、按项目、按月份三个维度展开，工作量自动汇总，一键导出。文章适合刚接触前后端分离开发的同学，也适合想快速搭一套内部管理系统的开发者，后端用Java，前端用Vue，数据库用MySQL，技术栈都是国内团队最常用的那一套。

1. 系统到底做什么：需求拆解与功能设计

开发之前先把需求问清楚，尤其是“工作量统计”这四个字背后的真实场景。一开始只说是“统计每个人干了多少活”，真去聊才发现要细分成很多情况：有人一天要做多个任务，一个任务跨好几天，月底要按人汇总、按项目汇总，还要分“已审核”和“未审核”的状态。这些不提前梳理清楚，后面改起来非常痛。

1.1 工作量统计在真实场景中的痛点

没上系统之前，多数团队用共享Excel表格统计工作量。月初建一张表，每人一行，每天往里填几小时、做了什么，月底负责人手工汇总。人员一多，问题马上出来：

• 格式不统一。有的人填“3小时”，有的人填“半天”，还有人写“上午”，汇总时根本没法直接加总。
• 填写不及时。月底补填是常态，补填出来的数据基本靠回忆，准确性没法保证。
• 权限没法控制。一张表大家都能看，有些项目的工时信息本不该全量公开。
• 汇总工作量巨大。负责人要把几十行的碎片记录按人按项目归类，还不能只靠Excel函数硬算。
• 历史数据查询困难。翻上几个月前的记录，得一个一个打开历史文件。

这套系统要解决的就是上面这些事。核心原则是：录入标准化（统一工作时长单位）、流程线上化（谁提交谁审核有记录）、统计自动化（汇总交给SQL和图表，不靠人肉）。

1.2 功能模块怎么拆：角色、流程、数据闭环

拆功能模块的时候，我按“角色-流程-数据”三个维度来思考。系统角色分成三类：

• 普通成员：自己的工作量填报、查看个人历史记录。
• 部门负责人：查看所辖成员的工作量，对填报内容做审核，查看团队统计报表。
• 系统管理员：维护用户账号、角色权限、项目信息。

流程上闭环是：成员提交工作量 -> 负责人审核 -> 审核通过后计入统计报表。如果某个填报数据不真实，可以驳回并填写理由，成员重新修改后再提交。这个审核环节可以保证月度汇总的数据是经过确认的，而不只是大家随手填的数字。

数据方面，工作量填报是最核心的记录表，围绕它衍生出项目表、用户表、角色表。报表统计则是从记录表聚合出来的结果。整个系统的数据流并不复杂，但每一步都要有明确的状态标记，比如记录是“草稿”“待审核”还是“已通过”，方便后续统计时过滤。

1.3 为什么选前后端分离而不是单页一体

项目立项时有人问我，这个规模也不大，直接用个服务端模板渲染不就行了，何必前后端分离。我的判断是：这套系统大概率不是一次性交付，后续还会扩展移动端、追加统计图表、甚至接入第三方登录，前后端分离可以让后续扩展省很多事。前端只通过接口拿数据，后端只提供JSON接口，边界清楚，出问题好定位。

另外一个现实好处是开发可以并行。前端负责页面交互，后端负责接口和业务逻辑，两个人同时开工，互不阻塞。我这次前端用Vue框架加开源的组件库搭建，后端直接启一个SpringBoot项目写接口，数据库表结构定下来后，两端的联调效率非常高。

做前后端分离最难的反而不是技术，是接口约定的管理。接口路径、参数、返回结构必须一开始就统一。我的做法是后端定义一个统一返回结构，包含code、message、data三个字段，前端封装请求方法统一处理。后面所有接口都走这个结构，联调阶段几乎没出现过“解析不到数据”的情况。

2. 后端设计与核心接口实现

后端基于SpringBoot构建，持久层用MyBatis，数据存储用MySQL。工作量的月度汇总、项目维度统计这些核心能力，本质上都是SQL的聚合查询，选MyBatis主要是看中SQL的可控性，复杂的统计SQL可以直接写清楚，性能也可以针对索引来做优化。

2.1 建表要点：工作量统计的库表怎么设计

数据库表设计决定了后面无论是功能开发还是统计报表，都会顺畅很多。这里给出核心表的结构和设计思路。

第一张表是用户表，字段包含用户ID、用户名、密码（BCrypt加密存储）、姓名、部门、状态。用户表和角色表是多对多关系，中间表存userId和roleId。密码一定不能明文存，这是底线。

第二张表是工作记录表，这是全系统的核心业务表。字段如下：

这里account特别注意f_month这个冗余字段。work_date本身是日期类型，完全可以用DATE_FORMAT函数从work_date里取月份来查询。但实际测试发现，一旦数据量上来，对work_date加函数运算会让索引失效，查询变慢。所以录入数据的时候直接把月份冗余存一份，同时在f_month和user_id上建联合索引，月度统计查询的速度非常快。这就是典型的“空间换时间”的取舍。

第三张表是项目管理表，字段包含项目ID、项目名称、项目编号、负责人ID、项目状态、开始结束时间。工作量填报需要选择所属项目，这张表就是项目数据源。第四张表是审核记录表，记录谁在什么时间审核了哪条工作量记录、审核结果是什么、备注是什么。这个表非常适合追溯，万一某条数据统计口径有争议，直接查审核记录。

2.2 月度工作量统计SQL：核心查询怎么写

工作量统计系统最关键的查询是按月统计每个人的总工时。这个SQL看起来不难，但有几个细节值得注意。

基础版SQL如下：

SELECT u.id AS user_id, u.real_name AS user_name, IFNULL(SUM(w.work_hours), 0) AS total_hours FROM sys_user u LEFT JOIN t_work_log w ON w.user_id = u.id AND w.f_month = '2025-01' WHERE w.status = 2 GROUP BY u.id, u.real_name ORDER BY total_hours DESC

这里两个容易踩的坑：第一，LEFT JOIN的过滤条件不能放在WHERE子句里，否则左连接会退化成内连接，导致没有填报记录的成员查不出来。所以月份条件放到了JOIN的ON子句里。第二，统计口径上只统计status为2（已通过）的记录，草稿和未审核状态的数据不算数，否则月底负责人看到的数字和上报的数字对不上。

按项目维度的统计类似，把它提成一个通用SQL模板：

SELECT p.id AS project_id, p.project_name, SUM(w.work_hours) AS total_hours, COUNT(*) AS record_count FROM t_work_log w LEFT JOIN t_project p ON w.project_id = p.id WHERE w.f_month = '2025-01' AND w.status = 2 GROUP BY p.id, p.project_name ORDER BY total_hours DESC

这段SQL配合前端报表接口使用，返回结果直接就是项目维度的汇总数据。

2.3 JWT登录鉴权：前后端分离时认证怎么做

前后端分离的项目不能依赖Session，因为前端页面和后端接口可能不在同一个域名下，而且移动端以后也要接同一套接口。这里我采用JWT做登录鉴权。

流程不复杂：

1. 用户输入用户名密码，后端校验通过后生成JWT令牌返回前端。
2. 前端把JWT存在本地存储中，每次请求在请求头上带Authorization: Bearer <token>。
3. 后端定义一个拦截器，从请求头解析JWT并校验签名和有效期。
4. 校验通过后把用户ID和角色信息放进请求上下文，供后续业务使用。

JWT的密钥要放到配置文件中，不要硬编码在代码里。过期时间我设置的是24小时，太短影响体验，太长有安全风险。对于内部管理类系统，24小时合理。

拦截器是核心。要放行登录接口，其他接口都要校验，同时处理token过期时的返回信息。我这边把校验逻辑写成一个HandlerInterceptor，在preHandle方法里做解析和校验，失败时直接返回401状态码加统一JSON结构。这里有一个要注意的细节：预检请求（OPTIONS）必须直接放行，否则前端跨域访问时会被拦截器挡住，联调时很容易怀疑人生。

2.4 接口清单与参数约束

后端做完，接口清单大概是这样的：

参数约束方面，work_hours必须大于0且不超过24，work_date不能晚于当前日期。项目经验是：后端接口越早做参数校验越好。一开始偷懒没校验，测试的时候前端把小数写成了字符串，到统计阶段数据直接乱了。后来统一用注解方式做参数校验，不合规的请求在进入业务逻辑之前就被挡掉了。

3. 前端页面与交互实现

前端用的是Vue框架配合组件库，后台管理类的页面本身对交互要求不算高，关键是表单录入的体验和统计图表的展示。工程结构按页面维度拆分，搭配路由和状态管理。

3.1 前端工程结构和登录态处理

前端工程的结构我按下面这种方式组织：

• 页面目录：login登录页、layout布局页、dashboard工作台、worklog填报页、worklogList记录列表、statistics统计报表页、project项目管理、user用户管理。
• 请求封装目录：统一处理axios实例的创建、请求头注入、响应拦截。
• 路由配置：配置页面路径和权限meta信息。
• 状态管理：存储用户信息、权限标识、当前选中项目。

登录态处理上，前端在路由切换前加一个全局前置守卫。如果没有本地存储的token，就跳转到登录页；如果有token但刷新页面时用户信息为空，就调接口重新获取。刷新页面不掉登录态，这个细节要处理好，否则用户体验很割裂。

axios响应拦截器里做统一的错误处理。token过期时返回401，拦截器内清除本地存储并跳转登录页。后端返回业务错误时，前端弹提示框显示message字段。这些统一的处理逻辑放在拦截器里，页面代码就不需要关心错误处理了。

3.2 工作量填报页：核心交互设计

工作量填报页是整个系统前端最核心的部分。设计原则是让成员尽量减少操作成本，否则大家都会排斥用系统。

我做了三件事来优化填报体验。第一，日期默认是今天，用户不用每次选。第二，项目字段做下拉搜索，项目多的时输入关键字直接过滤。第三，“保存”和“提交”分开。保存是把记录存成草稿，可以继续修改；提交则把数据推给负责人审核，提交后自己就不能再改了。这个交互设计对应后端status字段的0和1状态。

表单校验也要做。工作内容不能少于几个字、时长必填、日期必填，这些在前端做一遍快速提示，后端再严校验一遍。有同学问为什么前后端都要校验，省一端不行吗？答案是：前端校验是为了用户体验，后端校验才是真正的安全防线。绕过前端直接调接口是可以做到的，后端不校验等于裸奔。

填报记录列表和分页查询也在这个模块里。列表要显示每条记录的状态，待审核的显示“待审核”标签，已通过的显示“已通过”，被驳回的要显示驳回原因和修改按钮。这样成员能及时知道自己的填报是否被确认，形成闭环反馈。

3.3 统计报表与图表展示

统计报表这块，前端用柱状图加表格组合的方式展示。柱状图展示每个人月度总工时的对比，表格展示明细数据，按项目可切换维度。图表本身用开源图表库就能满足，不复杂，难在数据接入。

报表接口返回结构化数据后，前端要做一次数据映射，把后端字段映射成图表需要的格式。这个映射逻辑抽出来放成一个独立工具函数，方便多个页面复用。另一个细节是月份选择器，默认当月，可以往前翻历史月份。每次切换月份重新请求数据，数据加载时加Loading状态，体验就不会显得卡顿。

导出功能是一个隐藏的刚需。“工作量统计系统”做到后面，负责人最关心的就是月底能不能把报表导出发给上级。导出接口由后端生成Excel文件返回二进制流，前端通过Blob方式下载。这个功能看似简单，但要注意请求时带token：如果用普通链接直接访问下载接口，请求头里没有Authorization，会被拦截器挡在门外。前端必须用axios以blob类型请求，再从响应头取文件名。

4. 部署上线全流程

开发完代码只是第一步，真正让系统跑起来还需要部署。前后端分离项目的部署核心思想是：前端构建出静态文件，交给Nginx托管；后端打包成可执行的jar包，通过Java命令直接运行。整个过程我按“本地检查 -> 环境准备 -> 后端部署 -> 前端部署 -> 上线验证”五步走。

4.1 本地打包前要检查什么

打包这件事，最怕的是本地能跑，服务器上起不来。我一般会在打包前检查三个东西：

第一，检查数据库连接配置。本地连接地址往往是localhost，打包前要改成服务器对应配置，或者直接把配置外置到application-prod配置文件中，部署时通过参数指定，这样源码包和运行环境彻底分离。

第二，检查前后端接口地址。前端代码里请求的接口地址如果是localhost，打包出来肯定是废的。正确做法是把接口地址写成相对路径（如/api），由Nginx反向代理转发到后端服务。这样前端构建包不管部署到哪个域名下面都不用改代码。

第三，检查第三方依赖的版本兼容。强烈建议固定版本号，不要用latest。SpringBoot的版本、前端组件库的版本，锁定后部署环境才稳定。实际遇到过几次，开发时能用，重新拉依赖后版本更新导致各种怪异问题，排查起来非常耗时间。

4.2 服务器基础环境准备

部署这套系统需要的环境有：JDK运行时、MySQL数据库、Nginx。服务器操作系统我用的Linux发行版，这是最主流的部署环境。

JDK安装注意版本要和项目一致。SpringBoot版本对JDK版本有要求，装错了Jar包直接跑不起来。装完以后在终端里执行java -version看一下当前版本，确认无误再继续。

MySQL安装后要创建对应的数据库和账号。部署环境里的数据库建议单独创建一个业务账号，只授予当前数据库的权限，不要直接用root账号跑业务，安全考量多一些。创建数据库时指定字符集为utf8mb4，这个字符集才能完整支持中文和特殊符号，否则导入数据时中文可能变成乱码。

Nginx安装完成后，默认配置在/etc/nginx/目录下，主要改动的是站点配置文件。如果对Nginx配置不熟，操作前先把默认配置备份一份，改坏了能快速还原。

4.3 后端部署：jar包运行与进程守护

后端项目在本地执行打包命令，构建出可执行的jar包，上传到服务器指定目录。我用/opt/app作为部署目录，jar包直接放里面。第一次启动用下面的命令测试：

java -jar work-statistics-1.0.0.jar --spring.profiles.active=prod

这一步先在前台运行，观察启动日志。日志里出现“Started Application”说明启动成功。如果出现报错，多半是环境问题，比如端口被占用、数据库连不上。这些都解决后再进入下一步。

长期运行不能只靠前台启动。我这边用systemd来做进程守护，创建服务配置文件：

[Unit] Description=Work Statistics Service After=network.target [Service] Type=simple User=deploy WorkingDirectory=/opt/app ExecStart=/usr/local/java/bin/java -jar /opt/app/work-statistics-1.0.0.jar --spring.profiles.active=prod Restart=on-failure RestartSec=10 [Install] WantedBy=multi-user.target

配置好之后使用systemctl daemon-reload重载配置，然后systemctl start work-statistics启动服务。有了systemd管理，即使进程意外退出也会自动拉起，重启机器后服务也会自动启动。这一步非常关键，线上服务绝对不能裸跑。

4.4 前端部署：nginx托管与接口反向代理

前端构建命令执行后，dist目录里就是静态文件。把dist目录里的全部内容上传到服务器，放在Nginx配置的站点根目录下。

Nginx站点配置的核心是两块：静态文件托管和接口反向代理。配置如下：

server { listen 80; server_name your-domain.com; root /opt/www/work-ui; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location / { try_files $uri $uri/ /index.html; } }

第二段location里那行try_files $uri $uri/ /index.html非常关键。Vue是单页应用，路由切换是用前端路由实现的，如果用户在页面上按F5刷新，Nginx会去找对应的真实文件，找不到就会404。加上这行配置后，所有找不到的路径统一回退到index.html，前端路由接手渲染对应的页面。

接口代理这段把/api/开头的请求转发到后端8080端口的服务上。这样前端页面和接口就处于同一个域名下，不跨域，省掉很多跨域配置的麻烦。

4.5 数据库初始化与上线检查

数据库初始化用的是项目里的SQL脚本。执行完脚本后，可以先插入管理员账号，然后登录后台创建部门、项目、测试账号，走通一遍核心业务流程。

上线检查清单我一般固定看这几项：

• 登录页能不能正常访问，能不能登录成功。
• 刷新一个带路由的页面，比如/dashboard，会不会404。
• 填报一条工作量记录，看能不能提交。
• 负责人账号登录，看能不能看到待审核记录，正常审核通过。
• 切到统计报表页，看图表数据是否与数据库查询结果一致。
• 导出Excel，确认下载的文件能正常打开。

这六项全部走通，系统基本上就稳定可用了。我还会顺手测一下非法路径访问会不会弹到登录页、连续输错密码会不会被拦住，这些体验细节对内部系统的口碑影响很大。

5. 常见问题与排查实录

测试和试运行阶段，我其实遇到了不少问题。多数问题集中在环境配置和发布遗漏上，代码本身的Bug反而比较少。挑几个最典型的问题记录一下，给大家排雷。

5.1 前端请求接口404 / 502

现象是页面能打开，但列表数据为空，浏览器的开发者工具里看到请求接口返回404或502。404一般是接口路径不对，检查一下请求路径和后端Controller的RequestMapping路径是否完全一致。502则基本是后端服务没起来，或者Nginx代理地址写错了。排查的时候先去服务器上看后端日志，日志是最诚实的。

还有一种非常容易踩的情况：本地开发时前端走Vite的代理，路径是对的；部署时忘了把接口返回路径改成相对路径，代码里硬编码了localhost，那在服务器上必然白屏。所以前端请求统一走相对路径加Nginx代理，不要硬编码。

5.2 打包后前端页面刷新404

这是单页应用部署最常见的坑。部署完后访问首页正常，点进某个子页面再按F5，页面直接404。原因就是Nginx没有配置单页回退，静态文件服务器去找不存在的物理路径。解决方案就是上面写的try_files $uri $uri/ /index.html。这个配置加上后，问题立即消失。

5.3 数据库连接失败与时区报错

后端启动时经常遇到两类数据库报错。一类是连接被拒绝，检查数据库服务是否真的启动了、端口是否开放、用户名密码是否正确。另一类是时区报错，MySQL连接串需要加上时区参数。

我当时遇到的报错信息类似“连接数据库时区无法识别”，解决方法是连接串里显式指定：serverTimezone=Asia/Shanghai。或者直接在MySQL配置里设置默认时区。这个报错本质是Java连接器版本较新时，要求明确指定时区。

5.4 用户反馈：提交不进去、数据不见了

试运行期间有成员反馈提交不进去，后端日志看到创建记录的接口返回了参数校验失败。查下来是前端传的work_hours字段类型是字符串，后端用注解校验数值范围时直接报类型不匹配。这个在联调阶段就应该发现的，后端校验注解里明确标注了类型，但我一开始图省事只做了范围校验没做类型校验。后面在全局异常处理器里增加了类型转换失败的处理，并返回明确的中文提示，问题才算闭环。

“数据不见了”则多半出在审核未通过和统计口径上。成员以为填了就算数，负责人这边还没审核，月度报表自然不包含这些数据。这不算是Bug，是没跟使用方讲清楚流程。后来在统计报表页面增加了状态说明文字，类似“报表仅统计已审核通过的工作记录”，用户再没问过这类问题。

5.5 一套可以直接抄的避坑清单

最后整理一份避坑清单，都是实际项目里用教训换来的：

• 数据库连接串一定要带时区参数，连接池大小要设置合理值。
• 后端全局异常处理器必须覆盖参数校验异常和HTTP状态码异常，否则前端拿到的提示信息全是英文技术术语，使用方看了也不知道什么意思。
• 部署上传jar包前，用jps或ps -ef看一下旧进程是否还占用端口。
• JWT密钥和数据库密码不要硬编码在代码里，放到配置文件中并在部署时替换。
• 定时备份数据库，内部系统也要备份。我是用系统自带的crontab每天凌晨备份一次，保留最近7天的备份文件，数据量不大，成本非常低。
• 上线前把所有需要手动执行的SQL脚本整理成一个文件，按版本号命名。后面加字段、加表都按这个规范来，方便追溯也方便新环境初始化。

这套系统从开发到上线，核心的时间其实花在需求梳理和细节校验上，前后端分离本身并不复杂。我个人在实际操作中最满意的部分是报表统计和审核流程的闭环，有这两个模块，系统才真正解决了手工汇总Excel的痛点。测试阶段收到的最有价值的反馈是“导出Excel能不能加个文件名带月份”，这个改动很小，但使用方满意度直接提升一个档次。

这类内部系统做完之后，额外扩展的空间还有不少。比如在填报基础上加日报周报汇总、把工作量数据接入月度绩效计算、增加按季度维度的趋势图。底层的表结构和统计逻辑是稳的，往上加功能只是时间问题。最后再提醒一点：项目里所有环境相关的配置，能外置就外置，这是后续运维体验好不好的分水岭。