企业官网建设流程全解析

1. 工作量统计系统的核心定位：它到底解决什么问题

先聊一个很现实的问题：为什么需要一套独立的工作量统计系统？很多团队一开始都用共享表格、聊天记录接龙来统计大家干了多少活，一开始十几个人还能凑合，等团队上了几十人、任务拆到子任务级别、还要按周或者按月汇总绩效数据的时候，表格方案直接崩盘——数据对不上、漏报瞒报没人知道、领导要报表的时候你得熬一整夜手工整理。

这套系统解决的就是这些痛点。它的核心定位是：把“谁、在什么时间、做了哪个任务、花了多少工时、产出是什么”这些信息，从一个靠自觉填报的分散状态，收拢成一个有权限管控、有审批流程、有量化报表的集中管理平台。简单说，就是从“口说无凭”变成“系统留痕”。

具体到技术实现上，项目采用 Java SpringBoot 作为后端服务框架，Vue3 作为前端界面框架，MyBatis 作为数据持久层框架，搭配 MySQL 存储业务数据，整体采用前后端分离架构。这套组合在国内的企业级管理系统里非常成熟，招聘市场上人才储备也充足，后续找人维护不用发愁。

从使用场景来看，它适用于以下几类情况：

• 项目型团队：按项目拆任务，统计每个成员在项目上的投入工时。
• 部门日常管理：记录日常事务性工作的完成情况和工作量。
• 跨部门协作： A 部门提需求，B 部门承接实施，系统里留痕，结算时有据可查。
• 绩效考核辅助：为绩效评定提供量化数据支撑，减少主观争议。

如果你正好需要开发类似系统，或者你想学习一套完整的、可以直接落地的前后端分离项目源码，这篇内容会从业务设计、数据库建模、后端接口、前端页面到问题排查，完整走一遍。

2. 需求梳理与业务边界：开工前必须定清楚的几件事

2.1 工作量统计的核心指标怎么定义

工作量这个词听着简单，真落到系统设计里，要先回答几个问题：

• 按什么单位统计？是按“小时”还是按“任务个数”？
• 一个任务可以拆分给多个人吗？
• 任务是先派发再确认，还是先填报再审批？
• 统计周期怎么算？按自然周、自然月，还是按项目周期？

我在做类似系统的时候，通常是这么设计的：工作量 = 有效任务工时。每个任务由负责人创建，可以指派给多个执行人，每个执行人填报自己在该任务上的实际工时，然后由负责人或管理员审批。审批通过后的工时才进入统计报表，未审批的和被驳回的不计入。这套流程比单纯让员工自己填一个总数要严谨得多，也方便后续追溯。

还有一种做法是“派工单模式”，管理员直接给成员派活，成员只能确认不能自己填工时。这种模式适合任务分配非常明确的团队，但灵活性差一些。当前这个项目采用的更偏向填报加审批的模式，兼顾了灵活性和管控。

2.2 角色权限的划分

工作量系统涉及的数据比较敏感，权限设计不能马虎。一般的角色划分如下：

这套权限模型用 SpringBoot 的拦截器加注解就能实现，配合前端路由守卫做双保险。后端是真正的权限控制点，前端隐藏按钮只是提升体验，千万不能把权限安全寄托在前端。

2.3 功能模块拆分

整个系统按我的习惯，会拆成五个核心模块：

• 用户认证模块：登录、退出、密码加密存储、Token 鉴权。
• 项目管理模块：项目增删改查、项目成员维护、项目状态管理。
• 任务与工时模块：任务创建、任务指派、工时填报、工时审批。
• 统计报表模块：个人维度、项目维度、时间维度的多条件统计。
• 系统管理模块：用户管理、角色分配、操作日志、数据字典。

这五个模块边界清晰，每个模块都能独立开发测试，前后端对接起来也方便。从源码结构上看，后端包结构按模块划分，前端页面按视图划分，这一套组织方式对后续扩展非常友好。

3. 数据库设计：工作量统计系统的地基怎么打

3.1 核心表结构规划

数据库设计决定了这个系统能走多远。我建议核心表不要少于八张，包括用户表、角色表、用户角色关联表、项目表、项目成员表、任务表、任务执行人表、工时记录表，加上操作日志表。

拿任务表举例，关键字段大致如下：

CREATE TABLE task ( id BIGINT PRIMARY KEY AUTO_INCREMENT, project_id BIGINT NOT NULL COMMENT '所属项目ID', task_name VARCHAR(200) NOT NULL COMMENT '任务名称', task_desc TEXT COMMENT '任务描述', priority TINYINT DEFAULT 1 COMMENT '优先级 1低 2中 3高', status TINYINT DEFAULT 0 COMMENT '状态 0待开始 1进行中 2已完成 3已取消', creator_id BIGINT NOT NULL COMMENT '创建人ID', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_project_id (project_id), KEY idx_status (status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='任务表';

工时记录表是整个系统的核心，需要特别注意每个字段的含义：

CREATE TABLE work_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, task_id BIGINT NOT NULL COMMENT '任务ID', user_id BIGINT NOT NULL COMMENT '填报人ID', work_date DATE NOT NULL COMMENT '工作日期', work_hours DECIMAL(4,1) NOT NULL COMMENT '工时，支持0.5小时粒度', work_content VARCHAR(500) COMMENT '工作内容描述', status TINYINT DEFAULT 0 COMMENT '0待审批 1已通过 2已驳回', approver_id BIGINT COMMENT '审批人ID', approve_time DATETIME COMMENT '审批时间', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_task_id (task_id), KEY idx_user_id (user_id), KEY idx_work_date (work_date), KEY idx_status (status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='工时记录表';

3.2 设计时容易忽略的三个细节

第一，工时字段建议用 DECIMAL 而不是 INT，因为实际填报时经常出现 3.5 小时、0.5 天这种粒度，用整数会逼着用户四舍五入，数据失真。第二，所有业务表都要带 create_time 和 update_time，排查问题的时候能少掉很多头发。第三，逻辑删除优于物理删除，尤其是工时和任务这种数据，后来发现某个数据被直接物理删除找不回来，那种心情真的很难受。建议表中加一个 deleted 字段，查询时默认过滤。

索引设计上，不要盲目加索引，要根据查询条件来。工时记录表最常见的查询是按 userId + workDate 查个人某段时间的工时，按 projectId + taskId 查项目维度的工作量，所以索引要优先覆盖这两个方向。

4. 后端核心实现：SpringBoot + MyBatis 的关键细节

4.1 分层架构与包结构

后端如果用单一 Controller 写到底，前期是爽，后面想死的心都有。建议按经典四层结构来组织：

• Controller 层：接收请求，参数校验，返回统一响应体。
• Service 层：业务逻辑，事务控制，审批规则校验。
• Mapper 层：MyBatis 数据访问，SQL 写在 XML 里，避免注解 SQL 混在 Java 代码中难维护。
• DTO/VO 层：前端交互的数据载体，不要直接暴露数据库实体。

统一响应体我一般这样设计：

public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }

这样前后端对接时，只需要约定 code 和 message 的语义，不需要每个接口单独讨论返回格式，能省很多沟通成本。

4.2 登录认证与 Token 机制

工作量系统肯定不能裸奔，登录认证是标配。常用的方案是 Spring Security + JWT，但对于这个体量的系统，可以不用 Spring Security 那么重，直接用拦截器 + JWT 也能实现，代码更少，也好理解。

核心逻辑如下：

• 用户登录成功后，后端生成 Token，Token 里携带 userId 和角色信息。
• 前端把 Token 存在本地，每次请求放在请求头 Authorization 里。
• 后端写一个拦截器，从请求头解析 Token，解析失败直接返回 401。
• 需要做权限控制的方法上，用自定义注解标记角色，拦截器里校验。

密码存储必须用 BCrypt 加密，绝对不能明文存数据库。我见过有项目把密码明文放在数据库里，一旦数据库泄露，所有账号都完蛋，这是非常严重的低级错误。

4.3 工时填报与审批的业务逻辑实现

工时填报是最容易出现并发问题的环节。举个例子，用户提交一个任务工时时，系统需要校验该任务是否已结束、当天工时是否超出限制、该用户是否有权限操作这个任务。这些校验必须放在 Service 层的事务里，不能只靠前端表单校验。

审批环节要注意状态冲突。审批过程中，同一份工时记录不能被两个人同时审批，否则会出现重复计数。我处理的办法是加一个乐观锁版本号，更新时带上版本条件，更新影响行数为 0 就说明数据已被别人改过：

@Update("UPDATE work_log SET status = #{status}, approver_id = #{approverId}, approve_time = NOW() " + "WHERE id = #{id} AND status = 0") int approveWorkLog(Long id, Integer status, Long approverId);

这里最关键的就是 WHERE 条件里加上了 status = 0，意思是只有待审批状态才能更新成功。如果两个人同时点了审批，第二个人的语句会因为状态已经变了而更新 0 行，Service 层就能感知到冲突并提示“该记录已被审批”。

4.4 MyBatis 动态 SQL 处理复杂统计查询

统计报表功能是工作量系统里 SQL 最复杂的地方，因为它涉及多表关联、条件筛选、分组和聚合。MyBatis 的动态 SQL 在这里优势非常明显。

比如统计某个时间段内每个成员的累计工时，可以这样写：

<select id="statUserWorkHours" resultType="map"> SELECT u.id AS userId, u.real_name AS realName, IFNULL(SUM(wl.work_hours), 0) AS totalHours, COUNT(DISTINCT wl.task_id) AS taskCount FROM sys_user u LEFT JOIN work_log wl ON wl.user_id = u.id AND wl.status = 1 AND wl.work_date BETWEEN #{startDate} AND #{endDate} <where> <if test="projectId != null"> AND wl.task_id IN (SELECT id FROM task WHERE project_id = #{projectId}) </if> <if test="deptId != null"> AND u.dept_id = #{deptId} </if> </where> GROUP BY u.id, u.real_name ORDER BY totalHours DESC </select>

这段 SQL 用 LEFT JOIN 保证没有填报工时的成员也出现在统计结果里，totalHours 为 0，而不是被直接过滤掉。这是统计报表里非常容易踩的坑——用 INNER JOIN 会把没干活的人漏掉，汇报的时候领导会问“为什么张三不见了”。

5. 前端工程：Vue3 + 组合式 API 的项目实践

5.1 前端目录结构与工程化搭建

前端用 Vite 构建 Vue3 项目，目录结构我建议这样组织：

src/ api/ # 接口请求封装 assets/ # 静态资源 components/ # 公共组件 layout/ # 布局组件 router/ # 路由配置 stores/ # 状态管理（Pinia） views/ # 页面视图 login/ dashboard/ project/ task/ worklog/ report/ system/ utils/ # 工具函数

API 请求封装上，推荐用 Axios 实例统一配置 baseURL、请求拦截器和响应拦截器。请求拦截器里带上 Token，响应拦截器里统一处理业务错误码和 401 跳转。这样可以避免每个页面都写一遍错误处理，也让代码很干净。

5.2 核心页面：工时填报的交互设计

工时填报页面是用户每天都可能用的页面，交互设计上一定要快。

我的做法是采用“日历 + 列表”双视图模式。日历视图让用户直观看到每天是否已填报；点击某一天弹出填报表单，表单里可以选择任务、填写工时数和工作内容。列表视图则是按时间倒序展示当前用户的填报记录，每条记录都能查看审批状态。

表单校验需要注意：

• 工时数必须大于 0，且不能超过 24。
• 一个用户同一天不能针对同一个任务重复填报。
• 工作内容不能为空。

这些校验前端要做一遍，后端必须再做一遍。前端的校验是提升用户体验，后端的校验才是真正的数据安全防线。

5.3 报表展示的图表方案

统计报表页面需要展示趋势图和排名表。图表推荐使用 ECharts，配合 Vue3 的封装组件使用。

工作量趋势图用折线图展示，横轴是日期，纵轴是总工时；人员排名用横向柱状图；项目投入分布用饼图。ECharts 的配置项在 Vue3 里需要放在 onMounted 后初始化，并记得在组件卸载时销毁实例，避免内存泄漏。

这里有个实践经验：报表页面的数据不应该每次进入都重新请求全量数据，而是提供一个筛选区域，让用户选择时间范围和维度后再加载。全部数据一次性渲染几千条不仅在查询上压力大，前端渲染也会卡顿。

6. 前后端分离部署与联调的那些坑

6.1 开发环境跨域问题

前后端分离开发时，前端跑在 5173 端口，后端跑在 8080 端口，跨域是第一个要解决的问题。

开发环境最简单的做法是 Vite 配置代理：

// vite.config.js export default defineConfig({ server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } });

这样前端请求 /api/login 会被代理到后端服务的 /api/login，不需要后端开启跨域。生产环境则通过 Nginx 反向代理统一入口，前后端用一个域名，更安全也更便于维护。

6.2 后端接口联调时的状态规范

联调过程中最常见的问题就是接口返回格式不一致。我强烈建议前后端在项目启动前就把接口规范文档定下来，不要边写边改。规范至少包含这些：

• 请求方法、路径、参数类型。
• 返回统一 Result 结构。
• 分页参数用 pageNum 和 pageSize，返回数据里包含 total。
• 时间字段统一用字符串格式 yyyy-MM-dd HH:mm:ss。
• 枚举值的取值范围在数据字典里统一维护。

这些看似琐碎的约定，能节省大量联调时间。我见过团队因为没有约定时间格式，前端把时间戳当成字符串传，后端解析失败，两个人排查了整整一个下午，最后发现就是格式问题。

7. 典型问题排查实录与优化建议

7.1 统计结果和人工核算不一致

这是工作量系统最容易被质疑的问题。排查时按这三个方向走：

• 是否把未审批的工时记录计入统计？口径必须统一，报表里要明确过滤 status = 1。
• 是否有跨用户的重复填报？比如一个任务指派给三个人，三个人都填报了 8 小时，但任务本身只需要 8 小时。这种情况不是系统 bug，是业务逻辑的问题，需要任务负责人把任务拆分成更小的子任务。
• 是否有跨时区或日期边界问题？服务器时区和数据库时区不一致会导致按日统计偏差。

我处理这类问题的习惯是：在报表数据之外，给每条统计数加一个“数据来源明细”的跳转链接，让统计结果可以一层层下钻到原始工时记录。这样用户有疑问时可以直接核对明细，省了很多解释成本。

7.2 MyBatis XML 里 SQL 语句报错

开启动态 SQL 加 log 输出是排查 SQL 问题的第一步。在 application.yml 里配置：

mybatis: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

这样控制台会打印完整 SQL 语句，带参数值的那种，方便直接复制到数据库工具里执行验证。最常见的问题就是<if>标签里的条件写错，拼接出来的 SQL 语法错误或者 where 条件恒真，把整个表的数据都查出来了。建议每次写完复杂 SQL，先打印语句看一眼，再基于真实数据验证一遍。

7.3 响应慢：性能优化三板斧

系统用久了数据量上来，报表查询会变慢。优化顺序是：

• 先看 SQL 执行计划，确认是否命中索引。该加索引的地方别省。
• 再确认查询是否真的需要实时聚合，如果不是，考虑建立统计汇总表，每天定时任务刷新。
• 最后考虑缓存，报表数据用 Redis 缓存一段时间，不用每次查询都跑全量聚合。

对于企业内部的业务系统，第一板斧就能解决 80% 的问题。

7.4 源码二次开发时需要关注什么

拿到这套源码后要做二次开发，我建议先别急着改功能，先做三件事：

• 把数据库脚本跑通，确认基础数据能初始化成功。
• 把前后端项目分别启动，走一遍登录到报表的完整链路，确认自己能跑通。
• 读懂核心模块的代码流转：用户登录后 Token 怎么传递，任务创建后状态怎么流转，工时审批后数据怎么进报表。

这三件事做完，你对整个系统的理解会超过 80% 的人。然后再去改需求，比如把工时粒度从 0.5 小时改成 15 分钟，或者增加一个“加班时长单独统计”字段，都会顺手很多。

8. 落桌分享：我实际开发这类系统时的一些心里话

这套系统我在实际项目里做过不止一次，每次做都会发现新的问题。印象最深的一次，是统计报表上线后，有同事质疑“为什么我上个月明明干了很多活，统计出来却这么少”。后来一查，他发现是因为没有点提交审批，所有工时记录都停在待审批状态。这件事让我意识到：系统设计得再严谨，用户不按流程走就会出数据偏差。于是后来我在前端加了未提交工时的提醒角标，后端也提供了一个“本月未审批记录”的汇总接口，让问题前置暴露。

还有一次是把工时字段设计成 INT 整数，结果用户反馈“我做了两个小时零十分钟，怎么填”，最后逼着改成 DECIMAL 并支持 0.5 粒度，还加了自定义备注。所以后来我再设计这种系统，第一件事永远是把度量单位定好，前端表单、后端校验、数据库字段、统计口径全链路统一。

如果你打算拿这套源码学习或者做二次开发，我建议你把重点放在理解业务和代码的对应关系上。比如“审批通过后工时进入统计”这个规则，在数据库层面是 status 字段的变化，在后端是 update 语句的条件控制，在统计 SQL 里是对 status 的过滤。把这条线理清楚，整个系统你就吃透了大半。

最后分享一个小技巧：这类统计系统上线之后，最好先并行运行两周，让团队既用系统填报，也保留原有的手工统计，两边数据对照一下。没有异常后再停掉手工流程。这个过渡策略看起来保守，但对团队接受度和数据可靠性来说，是值得的。