企业官网建设流程全解析

1. 项目概述与核心需求拆解

1.1 这个系统到底解决什么问题

教师工作量管理，是每所高校和中小学教务管理中绕不开的痛点。以前靠教务处老师用Excel表格手工统计，一个学期结束要花两周时间收集、核对、汇总各院系的课时数据，中途还得反复打电话确认某个老师的外聘课时算不算数、实验课系数是0.8还是1.0。我接手这个项目时，客户方就明确提了三个诉求：第一，教师能自己申报工作量，不用再通过纸质单据流转；第二，教务处能在线审核、按学期自动汇总统计；第三，领导要能实时看到各院系的课时分布情况，而不是等期末出报表。

这个系统的定位很清晰，它不是一个大而全的数字化校园平台，而是一个聚焦教师工作量申报、审核、统计、导出全流程的垂直业务系统。前后端分离架构，后端用SpringBoot 2.7 + MyBatis，前端用Vue3 + Element Plus，数据库用MySQL 8.0。整套源码我在本地从零搭建，到最终部署到客户服务器，前后花了大约三周时间。写这篇文章，就是想把这个系统从设计到落地的完整思路整理出来，给正在做同类管理系统的开发者一个可参考的样板。

1.2 技术选型背后的考量

选技术栈这件事，很多人容易陷入"什么新用什么"的误区。我这个项目最终确定SpringBoot + Vue3 + MyBatis + MySQL，是基于以下几点实际考虑：

后端框架选SpringBoot而不是Spring Cloud。系统规模摆在那里，用户量就是一所学校的几百名教师，不需要微服务那套注册中心、网关、配置中心的复杂体系。SpringBoot约定优于配置的特性，能让单人开发把精力集中在业务逻辑上，而不是环境搭建上。我用的是2.7.x版本而不是3.x，因为3.x要求JDK17，而客户服务器上装的是JDK8，兼容性考虑必须排在第一位。

ORM选MyBatis而不是MyBatis-Plus或JPA。这是个值得说道的决策。工作量管理系统涉及大量多表关联查询和动态条件拼接，比如按院系、按职称、按学期、按课程类型组合筛选工作量明细。MyBatis的XML映射文件在这种场景下非常好用，SQL可控性最强。虽然MyBatis-Plus能省掉不少单表CRUD代码，但这种业务系统的核心价值就在那些复杂的统计SQL上，手写反而更灵活。JPA的话，复杂查询会变成一串让人头皮发麻的JPQL或者Criteria代码，调试成本太高。

前端用Vue3而不是Vue2。这个没什么好犹豫的，Vue3的Composition API在处理表单校验、复杂状态联动时确实比Options API顺手得多。配合Element Plus组件库，后台管理界面的开发效率很高。构建工具选的Vite，开发热更新速度比Webpack快了一个量级，这在调试工作量申报表单的时候体验特别明显。

数据库就用MySQL。学校环境里MySQL是绝对主流，运维老师都熟悉，而且这套系统的数据量撑死了几十万条，MySQL完全够用。字段设计上要注意的细节我在后面章节详细讲。

提示：如果你准备把这套系统作为毕业设计或课程项目参考，技术栈完全够用。但如果你是企业级商用部署，建议在审计日志、数据备份、并发控制这几个方向上再做加强，后面我会指出具体改进点。

2. 前后端分离架构设计与数据模型

2.1 整体架构设计

前后端分离架构在这个项目里的具体形态是：前端Vue3应用通过Axios调用后端RESTful API，后端SpringBoot以JSON格式返回数据，认证采用JWT Token机制。前端部署在Nginx上，后端打包成Jar包运行，两者通过HTTP通信。这个架构最大的好处是前后端可以并行开发，我跟另一个同事约定好接口文档后，他写页面我开始搞数据库和接口，互不阻塞。

系统分三个角色的权限体系：教师、院系管理员、教务处管理员。教师登录后可以申报工作量、查看审核进度、查看本人学期汇总；院系管理员负责审核本系教师的申报单，也可以帮系里老师代填申报；教务处管理员管全院系的最终审核，可以查看全校汇总报表、导出Excel，管理基础数据如课程信息、教师信息、工作量系数配置等。

权限控制的实现用的是拦截器 + 自定义注解的方式，没有引入Spring Security。说实话，Spring Security功能强大但配置繁琐，这个体量的系统用拦截器校验JWT和角色，代码量更少，逻辑也更直白。接口层面通过自定义注解@RequireRole标注需要的角色，拦截器里解析Token后比对角色，不匹配直接返回403。这套方案我用了很多次，稳定可靠。

2.2 数据库表设计

数据库设计是整个系统最见功力的地方。我总共设计了8张核心表：

用户表（sys_user）：字段包括id、username、password（BCrypt加密存储）、real_name、role（1教师/2院系管理员/3教务处管理员）、department_id、title（职称）、status。这里的department_id关联院系表，用于按院系维度做数据隔离和控制权限范围。

院系表（sys_department）：id、name、code。虽然表不大，但几乎所有查询都要关联它，"哪个院系工作量最高"是领导最常问的问题。

教师信息表（teacher_info）：id、user_id、employee_no（工号）、title、position、hire_date。这张表跟用户表是一对一关系，之所以拆出来，是因为教师的职称、教龄这些属性会变动，而用户的登录信息基本不变，拆开后互不影响。

工作量类型表（workload_type）：id、type_name、base_hours、coefficient。这里存的是工作量计算规则的基准值。比如理论课时基准是每学时1.0，实验课时系数0.8，实训课系数1.2，体育课按户外系数1.1折算。这是整个系统业务规则的核心配置。

工作量申报表（workload_application）：id、teacher_id、semester、course_name、class_name、student_count、class_hours（实际上课时数）、workload_type_id、coefficient、applied_hours（折算后工作量）、status（0草稿/1待院系审核/2院系已通过/3教务处已通过/4驳回）、submit_time、audit_remark。这张表是整个系统数据量最大的表，也是统计报表的数据来源。

审核记录表（audit_record）：id、application_id、auditor_id、audit_action、audit_comment、audit_time。所有审核操作都要记录留痕，这是审计需求，也是给老师看审核进度用的。

学时系数配置表（coefficient_config）：id、workload_type_id、grade（比如"普通班/合班/大班"）、min_students、max_students、coefficient_value。合班系数是这类系统里最容易出Bug的地方——一个老师带两个班合班上课，课时怎么算？我们的规则是学生人数达到合班标准（比如60人以上），系数乘1.1，超过90人乘1.2。这个规则不是拍脑袋定的，是跟客户教务处的制度文件逐条核对后的结果。

学期配置表（semester_config）：id、semester_name、start_date、end_date、is_current。方便按学期归档和切换，也用于控制申报时间窗口。

2.3 核心业务流程

整个系统的核心流程我梳理成了这样一条链：

教师填报：选择学期→选择课程名称→填写班级、实际上课时数→系统自动匹配工作量类型和系数→实时计算出折算工作量→保存草稿或提交审核。

两级审核：提交后进入院系管理员待办列表，院系审核通过后进入教务处管理员待办，两级都通过才算最终生效。任何一级驳回都要填写驳回原因，教师修改后可重新提交。

统计汇总：教务处可以按学期、院系、教师三个维度查看工作量汇总表。汇总的依据是所有状态为"教务处已通过"的申报记录，草稿和中间状态一律不进统计口径。

这个流程设计的关键点在于"状态流转要留痕、统计口径要唯一"。很多同类系统失败在统计数字对不上——教务处看到一个数，院系看到另一个数。根本原因就是没有把状态机设计清楚。我在代码里用了一个枚举类来定义状态常量，所有状态变更只能通过统一的服务方法操作，避免出现脏数据。

3. 后端SpringBoot+MyBatis核心实现

3.1 项目结构规范

后端项目的包结构我按照业务模块来划分，而不是按技术层划分。很多教科书教的"controller/service/mapper"三层包结构，项目大了以后会变成垃圾场。我采用的是按功能模块拆包的方式：

com.example.workload ├── common // 通用工具类、统一返回体、异常处理 │ ├── Result.java │ ├── PageResult.java │ ├── BusinessException.java │ └── GlobalExceptionHandler.java ├── config // 配置类 │ ├── WebConfig.java │ └── JwtInterceptor.java ├── controller // 接口层 │ ├── AuthController.java │ ├── WorkloadController.java │ ├── AuditController.java │ └── StatisticsController.java ├── service // 业务层 ├── mapper // MyBatis数据访问层 ├── entity // 实体类 └── vo // 视图对象

统一返回体Result<T>是前后端联调的基础设施。我的结构是{code: 200, message: "success", data: ...}，code非200时前端统一弹错误提示。这个统一返回体配合GlobalExceptionHandler使用，业务异常抛出BusinessException后统一转换为对应的返回码，Controller里就不用到处写try-catch了。

3.2 工作量大计算的核心逻辑

工作量自动折算这块是系统的技术核心，我单独讲一下。它的输入参数包括：实际上课时数（class_hours）、工作量类型（workload_type_id）、班级人数（student_count）。折算公式是：

实际工作量 = 实际上课时数 × 类型系数 × 合班调整系数

这个计算放在后端服务里，不在前端算。前端的实时预览只是调接口获取计算结果。为什么不在前端算？因为计算规则随时可能变，如果前端写死了，规则一改就要重新发版。放在后端，改一个配置就行。这是配置与业务分离的一个典型实践。

相关服务的核心代码如下：

@Service public class WorkloadCalculateService { @Autowired private WorkloadTypeMapper workloadTypeMapper; @Autowired private CoefficientConfigMapper coefficientConfigMapper; public BigDecimal calculate(Long workloadTypeId, Integer studentCount, BigDecimal classHours) { WorkloadType type = workloadTypeMapper.selectById(workloadTypeId); if (type == null) { throw new BusinessException("工作量类型不存在"); } // 基础系数 × 学时数 BigDecimal base = type.getCoefficient() .multiply(classHours); // 根据学生人数匹配合班调整系数 CoefficientConfig config = coefficientConfigMapper .findByTypeIdAndStudentCount(workloadTypeId, studentCount); BigDecimal mergeCoefficient = config == null ? BigDecimal.ONE : config.getCoefficientValue(); // 保留两位小数 return base.multiply(mergeCoefficient).setScale(2, RoundingMode.HALF_UP); } }

findByTypeIdAndStudentCount这条SQL是典型的范围查询：

<select id="findByTypeIdAndStudentCount" resultType="CoefficientConfig"> SELECT * FROM coefficient_config WHERE workload_type_id = #{typeId} AND #{studentCount} BETWEEN min_students AND max_students LIMIT 1 </select>

这里有个隐藏坑：如果配置表里同一类型存在重叠区间，LIMIT 1会随机取一条。所以在维护配置数据时要保证区间不重叠，我会在管理界面的保存逻辑里做区间重叠校验。

3.3 统计报表SQL的实现

统计报表是管理层最看重的功能，技术上最有挑战性的部分是"交叉统计"的SQL。我要实现一个按院系+职称维度统计工作量的透视表，效果是横向列出院系，纵向列出职称，中间填充各维度的工作量总和。

这个用纯粹的GROUP BY做不到行转列，需要结合条件聚合。我的SQL写法是：

SELECT d.name AS department_name, ti.title AS teacher_title, SUM(CASE WHEN wa.status = 3 THEN wa.applied_hours ELSE 0 END) AS total_hours FROM workload_application wa JOIN teacher_info ti ON wa.teacher_id = ti.id JOIN sys_department d ON d.id = ti.department_id WHERE wa.semester = #{semester} GROUP BY d.name, ti.title ORDER BY d.name, ti.title

这个SQL返回的是明细行，前端拿到后需要进一步转换成矩阵表格。另一种方案是用MySQL的GROUP_CONCAT在数据库端直接组装成JSON，由前端直接绑定。两种方案各有优劣：前者SQL简单、数据量几百行以内完全无压力；后者减少了一次数据映射，但SQL可读性差。我选择前者，把矩阵转换的逻辑放在前端JavaScript里，因为这类透视逻辑用JS处理更灵活。

3.4 批量审核与事务一致性

院系管理员审核时，最需要的功能是批量通过。但批量审核伴随一个事务一致性问题：如果选中10条记录，其中8条状态是"待院系审核"，2条已经是"教务处已通过"（可能页面延迟导致数据不同步），批量通过时不能简单更新所有记录，否则会覆盖已审核的状态。

我的处理方式是在批量审核的SQL里加上状态校验条件：

<update id="batchAudit"> UPDATE workload_application SET status = #{targetStatus}, auditor_id = #{auditorId}, audit_time = NOW() WHERE id IN <foreach collection="ids" item="id" open="(" separator="," close=")"> #{id} </foreach> AND status = #{expectedStatus} </update>

返回的影响行数与传入的ids数量做对比，不一致则提示"部分记录状态已变化，请刷新后重试"，同时整个方法加@Transactional回滚事务。这种"乐观锁"式的更新方式，能有效防止多人同时操作时的数据错乱。

4. 前端Vue3+Element Plus实现

4.1 前端项目搭建与目录结构

前端我用的Vite + Vue3 + TypeScript + Element Plus。TypeScript在这个项目里争议比较大，同事觉得增加工作量，但我坚持用，因为工作量申报表单的数据结构复杂，类型定义能帮我们提前发现很多字段拼写错误。实际开发中确实受益了，联调阶段的接口字段错误比以前纯JS项目少很多。

目录结构：

src ├── api // 接口请求封装 │ ├── auth.ts │ ├── workload.ts │ └── statistics.ts ├── assets // 静态资源 ├── components // 通用组件 │ └── StatusTag.vue // 状态标签组件 ├── router // 路由配置 ├── store // Pinia状态管理 ├── views // 页面组件 │ ├── login │ ├── dashboard │ ├── workload │ │ ├── WorkloadList.vue │ │ ├── WorkloadForm.vue │ │ └── WorkloadDetail.vue │ ├── audit │ └── statistics └── utils // 工具函数 └── request.ts // Axios封装

4.2 Axios拦截器与Token刷新机制

utils/request.ts是前端联调的核心，我封装了请求拦截器和响应拦截器。请求拦截器从Pinia里取Token加在请求头；响应拦截器统一处理code，code为401时清空登录状态跳转登录页，code非200时用Element Plus的ElMessage弹出错误信息。

Token过期处理这里有一个值得分享的经验：JWT Token一般设置2小时过期，但教师在填写工作量申报单时可能花很长时间，填完提交时Token恰好过期，体验会很糟糕。我的方案是前端拦截器检测到401后，不立即踢出登录，而是调用后端/auth/refresh接口用RefreshToken换取新Token，然后重放原请求。用户无感知地完成了续期。

这在Axios里有一个经典的实现技巧：在响应拦截器里做请求重放，需要用config对象重新发起请求。注意要把旧的config.headers合并到新请求里，否则自定义Header会丢失。

4.3 工作量申报表单的交互细节

WorkloadForm表单页是这个系统交互复杂度最高的地方。字段联动多：选择课程类型后，系数会跟着变；填写班级人数后，合班系数会跟着变；折算工作量实时计算更新。我用的是Composition API + reactive对象管理表单状态，用computed做实时计算结果。

关键交互逻辑是"先预览后提交"：用户填写完所有字段后，点击"试算"按钮，后端返回折算结果，前端在表单下方展示一个计算明细卡片，包含基准工作量、类型系数、合班系数、最终折算值。用户确认无误后再点提交。这个设计借鉴了报销系统的思路——先让用户看清楚钱是怎么算出来的，能大幅减少因理解误差导致的审核驳回。

4.4 统计报表的图表展示

统计页面的图表我用的是ECharts 5。主要展示三类图表：各院系工作量柱状图、各职称工作量占比饼图、学期工作量趋势折线图。

图表数据和表格数据共用同一套接口。前端拿到明细数据后用reduce函数做聚合计算，喂给ECharts的option。有个小技巧：因为图表要适配窗口大小变化，我在window.resize事件里做了防抖处理，避免频繁触发ECharts的resize方法导致性能问题。实测在窗口拖动时图表缩放非常流畅。

5. 系统部署与上线实践

5.1 本地开发环境配置

本地开发我采用的是一套双启动方案：前端Vite跑在5173端口，通过vite.config.ts里的proxy配置把/api路径代理到后端的8080端口。这样前端请求都是相对路径，不需要写死后端地址，部署以后只需改Nginx代理即可。

关键配置如下：

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

后端application.yml里配置数据源时有一个坑需要提醒：MySQL 8.0的驱动类名和连接URL参数跟5.x版本不一样。连接URL必须加serverTimezone=Asia/Shanghai参数，否则Java 8的时区跟数据库默认时区不一致，时间字段会差8个小时。我第一次连的时候没注意，测试数据的时间全部对不上，排查了半小时才发现是这个参数漏了。

5.2 线上部署步骤

线上环境我用的部署架构是：一台云服务器，Nginx代理静态前端文件并转发API请求，后端Jar包以服务方式常驻运行。具体步骤：

1. 前端执行npm run build，生成dist目录，将dist目录上传到服务器/usr/share/nginx/html/workload/目录。
2. Nginx配置server块，location / 指向dist目录，location /api/ 使用proxy_pass转发到http://127.0.0.1:8080/api/。
3. 后端项目执行mvn clean package -DskipTests打包成Jar，上传到服务器/opt/workload/目录。
4. 使用systemd创建服务文件，配置Jar包的启动命令和日志输出路径。
5. 启动服务后用curl测试健康检查接口，确认后端正常后再访问前端页面验证登录流程。

Nginx这块容易犯的错是proxy_pass的路径拼接问题。我踩过一次：直接在proxy_pass里写了http://127.0.0.1:8080/，结果前端请求/api/auth/login被转发成了/auth/login，后端接口路径对不上，全部404。正确写法是保留/api前缀转发，也就是http://127.0.0.1:8080后面不加斜杠，这样代理后会保留原始的/api路径。

5.3 环境差异问题

开发环境、测试环境、生产环境的配置差异管理也值得一提。我没有用Spring Boot的多profile配置来做环境区分，而是在部署时通过启动参数动态覆盖配置项。这样做的好处是同一个Jar包可以部署到不同环境，不需要针对环境重新打包。命令示例：

java -jar workload-system.jar \ --server.port=8080 \ --spring.datasource.password=实际密码 \ --spring.profiles.active=prod

密码作为启动参数虽然会出现在进程列表中，考虑到内网部署的可信环境，这个风险可以接受。如果安全要求更高，可以用环境变量Jasypt加密配置，这是后话了。

6. 常见问题与排查技巧实录

6.1 高频问题速查表

整个项目开发和测试阶段，我踩过的坑整理成了一张速查表，每次遇到类似问题都能快速定位：

6.2 排查问题的思路

遇到问题时，我的排查路径一般遵循"先确认数据、再确认接口、最后检查代码"的顺序。具体展开是这样：

先看数据库里的数据是不是符合预期。工作量统计数字不对，先手动跑一遍针对该教师、该学期的明细查询SQL，对比申报记录状态是否有异常。状态是"院系已通过"的记录没有被统计进去，那是统计SQL漏了状态条件；状态已经是"教务处已通过"但数字还是不对，那就是折算系数配置有问题。

再看接口返回。用Postman或curl直接调后端接口，传一组已知参数，看返回的JSON和计算逻辑是否匹配。这个环节能快速区分是后端计算错误还是前端展示错误。

最后才看代码。因为前两步能把问题范围缩小到具体的类甚至具体的方法，再定位就是开卷考试了。

6.3 印象最深的一个Bug

让我印象最深的一个Bug跟工作量计算精度有关。有个老师反映，他申报的一门理论课，折算结果差了0.02个学时。我查了申报记录，他填了18学时，类型系数是1.0，计算出来应该是18.0，但系统算出来是17.98。

问题是这么发现的：我复现了计算过程，发现系统里的课程系数配置成了0.99998，而不是1.0。为什么会变成这样？因为后台管理界面允许管理员编辑系数值，那个管理员的浏览器保存配置时小数精度没控制好，他把1.00000拖拽修改时误操作成了0.99998，自己还没意识到。

这个Bug的价值在于暴露了一个系统设计缺陷：配置数据缺乏精度校验和修改留痕。后来我在系数配置表的保存接口加了两层防护：一是输入框限制只能填精确到4位小数，超出拒绝保存；二是每次修改都写入审计日志，记录修改前后的值、操作人和时间。从此这个类型的Bug彻底消失了。

配置类数据的变更审计，在管理系统里真的不能省。业务数据有申报记录管着，配置数据往往没人管，而配置数据一错，影响的是所有后续计算结果，危害更大。

6.4 性能优化实录

系统上线后，发现学期末统计报表页面加载有点慢，大约3秒。查了原因：统计接口执行了多个复杂的聚合SQL，每次请求都实时计算，数据量到了几万条明细后确实吃力。

优化措施有两个方向。第一个是缓存：我用Spring自带的@Cacheable注解配合Caffeine本地缓存，对"课程类型列表"、"系数配置列表"这类几乎不变的基础数据做5分钟缓存，命中率极高，能省掉大量重复数据库查询。第二个是异步刷新：报表页面的图表数据改为后端预计算并缓存结果，第一次请求后缓存3600秒，过期后自动重新计算。这两个优化做完，页面打开时间从3秒降到0.5秒以内。

值得强调的是，优化前必须用数据说话。我加缓存前先看了慢查询日志，确认是多个聚合SQL叠加导致的延迟，而不是单纯的网络延迟或前端渲染慢。这样优化才有的放矢。

7. 扩展方向与二次开发建议

7.1 从管理系统到服务平台的演进

这套系统做完之后，我一直在想它还能怎么演进。教师工作量管理其实不只是统计核算，它完全可以演变成一个教师综合服务平台。比如把工作量数据跟科研积分、教学评价、年度考核打通，形成完整的教师绩效画像。技术上来说，工作量模块的接口设计成开放API，其他系统通过OAuth2授权对接，就能实现数据共享。

7.2 移动端适配思路

现在很多老师习惯用手机处理事务，但坐在电脑前填申报单的场景在移动端其实不太适用。我建议的移动端方案不是重新开发App，而是做一个H5轻量版，只保留三个核心功能：查看待办审核列表、快速审核通过/驳回、查看本人工作量汇总。H5页面通过WebView嵌入校园企业号或钉钉工作台，复用后端接口，开发成本很低。

如果你打算二次开发，我特别建议优先做消息通知模块。系统现在是通过待办列表被动触发，老师不会每天登录系统看有没有驳回。如果接入企业微信或钉钉的消息推送，审核结果实时触达，那系统的使用体验会迈上一个台阶。技术实现不复杂，就是在审核接口里调用消息服务，构造模板消息推送。

7.3 给新手的最后一些建议

做这类管理系统，我的体会是：技术难点不是最花时间的，最花时间的是把业务规则理清楚，让设计出来的功能真正贴合用户的使用习惯。教师申报工作量的操作频率很低——一个学期就几次——所以界面设计不能太复杂，要让一个不常登录的用户一次就能看明白怎么填。表单字段要精简，默认值要智能，计算过程要透明，审核状态要清晰。这些产品层面的细节，决定了系统是"有人用"还是"没人用"。

还有一点想分享的是：做这种源码开源分享类的项目，文档和代码注释的质量直接影响使用者能不能快速上手。我习惯在所有对外发布的代码里，给复杂方法写上方法说明和参数说明，给关键SQL配上业务场景注释。别人读代码时能省不少力气，自己三个月后回来看也容易找回当时的思路。赠人玫瑰，手有余香，写代码也应该这样。