企业官网建设流程全解析

教师工作量统计这种事，经历过的人都知道——平时没人理，期末一堆人围着数据表吵。我刚接到某高校这个需求时，心里其实没底。直到把 SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0 这套组合完整跑通，才发现问题真正的难点不在技术，而在工作量规则怎么建模。这套教师工作量管理系统源码本身不复杂，但涉及角色权限、批量导入、报表统计、权重计算这些模块，刚好能把主流 Java Web 技术栈串起来。我索性把这个项目的设计思路、实现过程和踩坑记录完整复盘一遍，给正在做类似管理系统的同学一份可直接参考的实操笔记。

系统的核心目标很简单：让教师自助填报工作量，系部管理员审核，教务管理员统一汇总并导出报表。但"简单"两个字背后藏着不少细节，比如讲师、副教授、教授上同一门课，工作量系数怎么算？跨校区上课要不要加分？实验课和理论课的权重差多少？这些业务问题没想清楚，代码写得再漂亮，上线第二天就会被老师们追着改。所以这篇文章的重点会放在规则建模和权限设计上，技术选型和具体编码也会给出来龙去脉，方便你在自己的项目里复现。

1. 项目立项背景：工作量统计为什么必须系统化

1.1 手工Excel统计的三大痛点

很多系部直到现在还在用 Excel 做工作量核算。表格发下去，老师们填完再收上来，教务员手动汇总，公式一拉，完整工作表就出来了。听起来没问题，但真正经历过三个周期以上的统计，就会发现痛点非常固定。

第一是版本混乱。一份工作簿在十几个人手里传来传去，经常出现 A 老师改完发到群里，B 老师基于旧版继续填写的情况。到了汇总阶段，同一门课可能出现在两个版本的表格里，教务员只能逐行核对，一遍下来眼睛都花了。

第二是公式不可控。Excel 里写 VLOOKUP、SUMIF 的时候很痛快，但那是对设计者而言。换一个人打开文件，根本不敢动里面的公式，动一步错十步。更麻烦的是，有些老师会手动修改公式单元格，把原始教学工作量直接改成自己计算后的数字，导致最终汇总完全没有统一口径。

第三是追溯困难。某个学期的系数规则调整了，比如实验课权重从 0.8 提到 0.9，那历史数据怎么办？Excel 里只能靠人工另存版本，根本没法做到"改一个规则，全系统自动重算"。所以很多高校想要系统化，不是赶时髦，是被 Excel 折腾够了。

1.2 需求梳理：谁在用、要什么

动手写代码之前，我花了两周时间跟着教务员走了整个统计流程。最终把用户角色归纳成三类：普通教师、系部管理员、教务管理员。三类角色对系统的诉求完全不同。

普通教师只关心三件事：能不能快速填报本月工作量，能不能随时查看自己累计完成情况，以及提交后能不能在审核前反悔修改。系部管理员想要的是审批流和统计核对，他们需要看到本系所有教师的数据并逐条确认，还要能快速筛出漏报、错报的记录。教务管理员则关注全校汇总、跨系的横向对比，以及导出符合人事处模板要求的报表文件。

这里容易犯一个错：一上来就设计复杂的工作流引擎，把角色和权限交叉得很花哨。实际上这类系统用最朴素的 RBAC 就够了——用户表、角色表、用户角色关联表，再加上菜单和按钮级别的权限控制。遇到特殊规则，比如系部管理员可以看本系数据但不能改其他系数据，这种"数据范围"不靠权限表硬写，而是靠查询时拼接部门过滤条件来实现。权限模型简单，后面维护成本就低。

2. 技术选型复盘：为什么是SpringBoot2而不是SpringBoot3

2.1 后端选型的现实考量

现在 Spring Boot 已经出到 3.x 了，新项目为什么还要用 SpringBoot2？我在这个项目里没有盲目追新，核心技术栈定在 SpringBoot 2.7 + MyBatis-Plus 3.5 + MySQL8.0，主要有几层考虑。

首先是生态兼容性。许多高校信息中心现有的基线环境、安全扫描工具、监控插件，对 Spring Boot 3 的 Jakarta EE 9 规范支持还不够成熟。Spring Boot 2.7 的 javax.* 命名空间在老体系里几乎没有兼容成本。其次是开发团队的技术熟练度，如果接手的人对 Spring Boot 2 更熟，出问题能更快定位。从交付角度看，稳定比新奇更值钱。

MyBatis-Plus 的选择则很务实。工作量管理系统里单表 CRUD 占了七成以上，MyBatis-Plus 的 BaseMapper 直接让你少写一大半样板代码。假设教师表、课程表、工作量明细表都要做增删改查，用原生 MyBatis 要写对应的 XML 和接口方法，而 MyBatis-Plus 只需要继承一个接口就够了。再者，它内置的分页插件、条件构造器、逻辑删除，几乎是为这类管理系统量身定做的。

数据库选 MySQL 8.0 没什么悬念。8.0 的窗口函数在统计报表里非常好用，比如计算教师工作量排名、环比增长，一条 SQL 就能搞定。另外 8.0 默认的 utf8mb4 字符集对表情符号和中文姓名处理更稳妥。如果你从 5.7 迁移过来，要注意驱动版本必须换到 8.x，连接串里也要显式声明 serverTimezone，这个坑后面会细说。

2.2 前端选型与工程结构设计

前端我选了 Vue3 + Vite + Element Plus。Vite 比 Webpack 的启动速度快太多了，尤其在开发阶段，热更新几乎是秒级。Element Plus 是 Element UI 的 Vue3 版本，表格、表单、弹窗、日期选择器这些后台管理核心组件都齐，不用自己造轮子。

工程结构上我采用前后端分离：前端单独一个项目，端口 5173，后端 Spring Boot 占 8080，通过 Nginx 在部署时统一代理转发。开发阶段用 Vite 的 proxy 解决跨域，线上则由 Nginx 把 /api 前缀转发到后端服务。

有一个细节值得提醒：Vue3 项目里路由懒加载一定要开，否则首屏会把整包 JS 全拉下来，体感会明显卡顿。工作量管理系统的页面不少——登录页、工作台、填报页、审核页、报表页、系统管理页，如果不懒加载，打包体积很容易突破 1MB。用import()动态导入组件后，首屏只需要加载当前页面对应的 chunk，我在实际项目里首屏时间从 3 秒多降到 1 秒以内。

3. 数据库与工作量规则设计：一张权重表解决所有争议

3.1 核心表结构拆解

数据库设计是这个项目的灵魂，工作量要想算得清楚，表结构必须先立住。我最终设计了六张核心表：

这里 workload_rule 是我刻意做的"规则配置化"设计。很多类似项目把工作量系数直接硬编码在 Java 代码里，例如：

if ("实验课".equals(course.getCourseType())) { score = hours * 0.9; }

这种做法最直接的坏处是：每次系数调整都要改代码、重新打包、重新部署。而我把它拆成一张表，管理员在后台就能维护"课程类型 -> 系数"的映射，系统运行时读表动态计算。比如理论课系数 1.0，实验课 0.9，实践课 1.2，每学期都可能微调，改表比改代码安全得多。

workload_record 里的 final_score 是冗余字段，用来缓存最终计算得分。虽然理论上可以通过查询时实时计算，但月末统计高峰期动辄上万条记录，每次都去关联权重表算一遍性能不划算。数据写入或者规则调整时统一重算一次，查询直接读缓存字段，这是典型的空间换时间。

3.2 工作量计算逻辑的落地方式

工作量计算的核心公式可以抽象成：工作量得分 = 课时数 × 课程类型系数 × 职称系数 × 教学质量系数。其中课程类型系数来自 workload_rule，职称系数来自用户表中讲师/副教授/教授的映射，教学质量系数则由审核环节去调整。

我建议把计算逻辑收敛到一个统一服务类里，比如 WorkloadCalculator，不要让计算散落在各个 Controller。这样做的好处是，无论教师填报、管理员批量导入、还是规则修改后重算，都调用同一个入口。假如某天领导说"本学期实验课系数从 0.9 改成 1.0"，你只需要更新 workload_rule 表中的记录，然后调用重算接口把本学期所有记录重新算一遍。

重算接口要小心并发问题。规则更新时，可能有老师正在填报数据。最简单的处理是给 workload_rule 的更新操作加乐观锁，版本号变化后，新写入的记录使用新规则，旧记录保持原值并标记为"历史规则"。我在实际项目里加了一个 effective_date 字段，规定规则的有效起始日期，历史学期的数据不会被重算逻辑影响，这个设计在和教务管理员核对数据时帮了大忙。

4. 后端开发实战：权限控制、批量导入与事务边界

4.1 RBAC权限模型的设计细节

正统 RBAC 是"用户 -> 角色 -> 权限"三层，我在此基础上增加了部门维度，用于控制数据可见范围。sys_user 表里存 department_id，查询工作量记录时，系部管理员只能看到本部门的记录，教务管理员则通过一个 isAdmin 标识跳过部门过滤。这种"垂直权限"的代价很低，却能很好地解决"系部管理员能看到全校数据"的越权风险。

菜单权限用权限字符标识，比如workload:record:submit和workload:record:approve。后端的核心实现是在方法上加自定义注解，拦截器解析用户权限集合，遇到标识缺失就返回 403。这里有个常见坑：前端隐藏菜单不能当作安全手段，如果后端每个接口不校验权限，有人直接拼 URL 就能越权。所以我在所有写操作接口上统一加了权限校验，查询接口也按需校验，避免通过遍历接口获取全校数据。

登录认证用的是 JWT。Spring Boot 方面，拦截器负责从 Header 里取 token，解析用户信息放进 ThreadLocal。要注意 token 过期时间不能太长，又不能太短。我设置的 access token 有效期是 2 小时，refresh token 有效期 7 天。这类内部管理系统并发不高，引入 Redis 做会话共享是过度设计，直接用无状态 JWT 更省事。

4.2 批量导入与数据校验的坑

工作量系统上线初期，历史数据都在 Excel 里，必须支持批量导入。我用的是 EasyExcel，这是阿里巴巴的库，内存占用比 POI 低很多，几万行数据也能平稳解析。

导入最大的坑不是读取文件，而是数据校验。Excel 里一行的字段可能为空、格式不对、教师姓名在系统里不存在。我设计了一套三段式校验：先做格式校验，再做业务校验，最后做重复性校验。格式校验检查课时数是不是数字、学期是否在合法区间；业务校验检查课程 ID 是否存在、教师是否属于当前系部；重复性校验检查同一位教师同一门课同一学期是否已存在记录。

这三段校验要全部通过才允许插入，任何一条失败都整行跳过，并把错误原因记录到导入结果文件里。系统前端会展示"导入成功 98 条，失败 2 条，点击下载错误明细"。这个交互非常实用，教务员拿着错误明细就能直接反馈给老师修改，不用自己一个个找原因。

这里再强调一下事务边界。批量导入如果一万条里有一条失败，不能全量回滚，否则好的数据也丢了。我的做法是分批插入，每批 500 条独立事务，本批内有失败就记录异常，不影响其他批次。这也是 EasyExcel 比较推荐的方式——先逐行校验，校验通过的放入 batch，积累到 500 条再 flush。

4.3 事务与并发：期末高峰期怎么防重复提交

期末是工作量填报的集中爆发期，会出现同一位老师短时间内反复点击"提交"按钮的情况。如果不做处理，就会产生两条一模一样的记录。前端可以禁用按钮，但后端必须兜底。

我用两种方式双保险。第一是在 workload_record 表上建立联合唯一索引，字段组合是 user_id、course_id、semester_id，重复插入直接抛 DuplicateKeyException。第二是用数据库行级锁或者 select for update 处理"按学期汇总"这类查询，避免并发更新把数据算错。实际开发中很多同学只做了前端防重复点击，上一个年级的项目就是这样，上线第一个月末就有老师连点了两下，结果多了一条工作量记录，最后还是手工删掉的。

事务注解 @Transactional 也要控制好范围。千万不要在 Controller 方法上直接加，因为 Controller 里可能要做文件上传、调用外部接口、发送通知，这些操作如果混进事务里，会长时间占用数据库连接。我的规范是：事务只加到 Service 层的写方法上，Controller 保持轻薄。

5. 前端开发实录：Vue3看板与报表可视化的实现思路

5.1 项目管理与接口规划

前端我用 Composition API 写defineOptions和<script setup>，状态管理用 Pinia。Pinia 比 Vuex 4 更简洁，对 TypeScript 的支持也更好，定义 store 的方式更接近普通对象，新手几乎没有学习成本。

接口规划上，一张工作量表会有三种展示维度：教师看自己按月的条形图，系部看各教师汇总的排行表，教务看全校各系对比的柱状图。因此后端接口不能只写一个getWorkloadList，而是拆成按用户、按部门、按全校三个查询入口，这样前端拿到数据就能直接接入 ECharts，不用在浏览器里二次过滤。

接口返回结构我做了一个统一封装：{ code, message, data, page }。其中 page 包含总数、当前页、每页大小。前端 axios 拦截器统一处理 code 非零的情况，弹 ElMessage 错误提示。这是很常规的做法，但我见过太多项目每个接口各写各的返回结构，导致前端到处判断 null，非常痛苦。

5.2 工作量看板的设计

教师首页的看板是用户最常用的界面，我不能只丢几个数字上去。我设计了三个模块：本月工作量完成度环形图、本学期各月趋势折线图、未审核记录列表。

环形图用 ECharts 的 pie 类型，把"本月已完成工作量"和"目标工作量"两个值放进去，视觉效果直观。折线图的数据来自/api/workload/statistics/trend接口，返回最近六个月的得分数组。未审核记录列表则是普通表格，行尾提供"编辑"和"撤回"按钮，方便教师在管理员审核前修正错误。

实现上有个细节：ECharts 在 Vue3 里应该用ref绑定图表实例，组件卸载时手动调用dispose()释放实例，否则用户在页面间反复切换会产生内存泄漏。我一开始没处理，跑了一天后浏览器标签页的占用内存蹭蹭往上涨，排查半天才发现是这个原因。

5.3 报表导出与打印

后端导出报表我用的是 Apache POI 的 XSSFWorkbook，生成 xlsx 文件。导出接口设计成异步更稳妥，因为全校半年数据生成文件可能需要几秒，同步请求容易超时。我的做法是：接口先创建导出任务，返回任务 ID，前端轮询任务状态，完成后给下载链接。

导出模板要和人事处的模板尽量一致，这一条算是经验教训。第一次上线时我按自己的想法做了个"整齐美观"的表格，教务员拿到后发现和学校下发的空表格式对不上，又让我重新改了一版。所以在做导出功能前，一定先找业务方要模板，确认表头、字段顺序、合并单元格这些细节，不然很容易返工。

打印功能反而比导出简单。前端只要把报表区域用 CSS 的@media print样式控制好，把无关的侧边栏、导航栏隐藏掉，直接调用浏览器的打印命令就行。很多老师不会用 Excel 调整打印区域，所以系统里加一个"打印"按钮，输出为 PDF 留存，实际使用率很高。

6. 部署上线与排错手记：从"本地能跑"到"正式可用"

6.1 打包部署的完整流程

开发环境跑通只是第一步，交付给学校信息中心后，还要走一套标准部署流程。前端在服务器上执行npm run build，生成 dist 目录；后端用 Maven 打成 jar 包。我用 Docker Compose 排列 MySQL、Redis（如果有）和 Nginx，服务统一通过内网端口暴露，外部只保留 443 的 HTTPS 入口。

给一个可以直接抄的 Nginx 配置片段：

server { listen 443 ssl; server_name workload.example.edu.cn; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location / { root /opt/workload/frontend/dist; try_files $uri $uri/ /index.html; } }

这里最容易忽略的是前端路由的 history 模式。Vue3 如果开启 history 路由，用户直接访问 /report 页面刷新，Nginx 只按目录找文件肯定 404。上面的try_files $uri $uri/ /index.html;就是解决这个问题的，所有未知路径都回退到 index.html，由前端路由接管。

数据库初始化也很关键。仓库里的 SQL 脚本要能幂等执行，建议带上CREATE TABLE IF NOT EXISTS和INSERT IGNORE，这样信息中心重复执行也不会报错。后台管理系统的账号密码不能写在 SQL 脚本里明文保存，我统一用一个初始化配置类，在系统首次启动时检测超级管理员是否存在，不存在则用 BCrypt 加密后写入默认密码，并强制首次登录修改。

6.2 三个值得记录的坑

第一个坑是 MySQL 8.0 时区问题。启动后端时频繁报告The server time zone value 'GMT+08:00' is unrecognized，数据库连接全部失败。解决办法是在 JDBC 连接串里显式加上serverTimezone=Asia/Shanghai，同时数据库执行SET GLOBAL time_zone = '+08:00'。凡是新建项目我都会先把这个配置写好，免得第一天就被它绊倒。

第二个坑是 MyBatis-Plus 分页插件在 Spring Boot 2 里的配置。新版分页插件要单独引入 mybatis-plus-jsqlparser 依赖，否则page()方法虽然执行了，但返回的分页对象里 total 永远是 0。这个坑非常隐蔽，表现是页面表格正常显示第一页，但"共多少条"的统计数字不对。把配置写对后，total 才能正常统计出来。

第三个坑是 JWT 密钥的硬编码。一开始我把密钥直接写在 application.yml 里，后来做安全审查发现问题，密钥一旦泄露，攻击者可以伪造任意用户身份。最终我把密钥放在环境变量里，生产环境由运维单独注入，开发环境才使用默认值。同时加了密钥定期替换的机制，虽然内部系统用得少，但不能因为面向内部就放松这个底线。

再补充一个和代码无关但真实存在的坑：打包的 jar 包默认内存占用在 512MB 左右，学校服务器经常只给 2GB 内存。如果同时跑 MySQL 和 Nginx，内存可能顶不住。我建议在application.yml里显式配置 Tomcat 最大线程数和连接数，并且给 Spring Boot 设置-Xmx512m的启动参数，防止内存溢出导致服务半夜挂掉。

最后说说我个人的体会。这种管理系统最耗时的从来不是增删改查，而是把业务规则翻译成系统逻辑的过程。工作量系统的核心就是那张权重表，花再多时间细化它都值得。很多同学拿到类似需求就直接建表写代码，结果数据结构撑不住业务变化，后期返工成本极高。先和真正的使用者反复确认流程，再把规则抽象成配置数据，这才是这类管理系统能顺利落地的关键。如果以后要在这个项目上做扩展，可以考虑接入消息通知，让审核状态变化直接推送到教师微信或邮箱，管理体验会再上一个台阶。