1. 项目整体设计与拆解思路1.1 为什么选前后端分离架构做教师工作量管理系统这类典型的管理类Web项目最怕的不是功能做不出来而是做到一半被各种历史包袱拖死。我在接手这个题目时第一反应就是把技术栈定死在SpringBoot Vue这套前后端分离的组合上理由很直接第一SpringBoot对Java Web开发体系的整合已经到了非常成熟的程度一个内嵌Tomcat就能跑起来的应用部署成本和维护成本都比传统SSH项目低太多第二Vue在中小型管理后台的开发效率上有天然优势组件化开发让页面复用变得非常简单而且生态里现成的UI组件库能让大部分后端同学不用花太多精力在前端样式上。这个项目的核心场景是教师工作量管理说白了就是解决高校里“老师本学期上了多少课、带了多少学生、做了多少项目、发了多少论文”这些数据的登记、审核和统计问题。它天然就是一个CRUD密集型应用但难点在于流程控制——老师提交工作量单需要经过教研室、院系、教务处多级审核每一级都有退回、通过、修改的操作空间。这类业务如果放在传统的JSP页面里写前后端代码揉在一起维护起来简直是灾难。而前后端分离之后后端的接口只关心数据流转前端页面只关心交互展示两边可以并行开发进度完全不受对方影响。另外还有一层考虑这个项目是要作为毕业设计来展示的。一个前后端分离的项目在答辩时可讲的东西会丰富很多——后端有鉴权、有拦截器、有Excel导出前端有路由守卫、有状态管理、有图表可视化。无论老师从哪个角度提问你都有东西可以展开。这比一个单纯的“增删改查”项目要有深度得多。1.2 功能模块与数据表设计的对应关系教师工作量管理系统的功能模块我一般会拆成四大块系统管理、基础数据维护、工作量申报与审核、统计报表。每一块都和数据库中的若干张表紧密绑定所以在动代码之前先把表结构设计明白项目就等于成功了一半。系统管理这块是最标准的包括用户、角色、菜单、权限四个维度。对应到数据库里就是sys_user、sys_role、sys_menu、sys_user_role、sys_role_menu这几张表。这里有个关键设计决策角色的权限控制用的是RBAC模型后端用拦截器校验接口权限前端用路由守卫控制页面访问双端都做校验而不是只信任前端的跳转控制。基础数据维护这块主要是教师信息表teacher_info、课程信息表course_info、项目信息表project_info。这里我特意把教师信息从用户表里拆出来因为用户的登录账号和教师的档案信息是两码事——一个老师可能有多个登录角色但教师档案只有一份。这种拆分在数据库设计上看起来多了一张表但后面扩展会非常舒服。工作量申报与审核是业务核心对应workload_record、workload_audit两张表。workload_record保存每一条工作量申报记录包括申报类型教学、科研、社会服务、工作量数值、申报人、申报时间、当前状态。workload_audit保存每一步的审核记录包括审核人、审核意见、审核时间、审核结果。其实这就是一张简单的审批流表不需要引入Flowable这些重量级工作流引擎用一张表加一个状态字段就能完成多级审核的需求。统计报表这块直接在SQL层面做聚合查询不额外建表。按月、按学期、按学年统计工作量总和按教师维度汇总按院系维度汇总。所有这些统计逻辑都可以通过一条Group By的SQL搞定后端只需要根据前端传入的时间范围和统计维度动态拼SQL即可。2. 核心技术点与实现细节2.1 SpringBoot后端核心接口设计原则后端接口的设计遵循一个原则每个接口只做一件事并且把这件事做透。这样写出来的接口文档才清晰也方便前端调用。以工作量申报模块为例我拆出了这些接口提交申报、查询我的申报列表、查询待审批列表、通过审批、退回审批、撤回申报。每一个接口都对应一个明确的业务操作而不是设计一个万能接口让前端传一个操作类型字段进来。在具体实现上我建议用MyBatis-Plus作为持久层框架。很多人纠结MyBatis和MyBatis-Plus怎么选我的观点很明确这种管理系统的增删改查占了80%用MyBatis-Plus的BaseMapper可以少写无数行重复代码剩下那20%复杂查询直接用自定义SQL解决。比如我统计工作量报表的时候写了一段多表联查加条件动态拼接的SQL既能享受MyBatis的动态SQL功能又不用绕开框架的局限。接口统一返回结果封装是另一个容易被忽略但非常影响开发效率的细节。我用了一个Result类包含code、message、data三个字段所有接口都返回这个结构。前端通过code判断请求是否成功success为200业务异常为400未登录为401无权限为403。这样前端在axios的响应拦截器里就可以统一处理错误提示和跳转登录不需要每个页面都写一遍错误处理逻辑。参数校验这里我用的是javax.validation的注解体系。比如提交工作量申报的时候必须有申报类型、工作量数值必须大于0、备注不能超过500字——这些都在实体类上加上NotBlank、NotNull、Min这类注解然后在Controller方法参数上加Validated。这个方法的好处是校验逻辑和业务逻辑完全分离代码看起来干净很多。更重要的是这样处理过的接口在Swagger文档里会自动生成参数说明前端同学不用翻代码就能知道每个字段的约束条件。2.2 Vue前端页面结构与状态管理Vue这一侧我用的Vue 2 Element UI的组合虽然Vue 3已经出来蛮久了但Element UI在Vue 2下的生态成熟度仍然很高网上资料多遇到问题容易找到解决方案对毕业设计来说稳定性优先。对于更追求新技术的同学也可以换成Vue 3 Element Plus核心逻辑差别不大。前端项目的目录结构我习惯这样组织views目录放页面组件router目录放路由配置store目录放Vuex状态管理api目录放所有接口请求封装utils目录放工具函数。api目录是我特别想强调的点每个后端接口都在api目录下的对应Js文件里封装成一个函数页面组件只负责调用函数不直接写axios请求。这样做的好处是当前端页面的接口调用比较集中时一旦后端地址有变或者接口参数调整只需要改api目录下的一个文件不用满项目找代码。路由守卫是前端鉴权的关键点。在Vue Router中配置一个全局前置守卫每次路由跳转前先检查token是否存在不存在就跳转到登录页存在但访问的是管理员专属页面就检查当前用户的角色信息非管理员直接跳转403页面。同样的逻辑我在后端拦截器里也做了一遍前端控制的是用户体验后端控制的是数据安全两者缺一不可。状态管理方面我用Vuex保存的是当前登录用户的信息、角色列表和菜单列表。因为很多页面都需要判断当前用户的身份来渲染不同的操作按钮比如普通老师看不到“审核通过”按钮教研室主任可以看到但看不到“最终审核”按钮。把这些信息放在Vuex里在所有组件中都能通过this.$store.state.user访问避免每个页面都要重新调接口获取。2.3 SQL脚本从建库到初始数据的完整设计SQL脚本是整个项目中容易被低估的一环很多人随手写几张表就开始做代码结果做到一半发现少字段、少关联、初始数据不全又回头改表白白浪费大量时间。我这份项目的SQL脚本分三个部分。第一部分是建库和建表语句。建库时注意指定字符集为utf8mb4而不是utf8因为utf8在MySQL中最多只能存3字节的字符遇到生僻字或表情符号就会报错。utf8mb4是utf8的超集能存储所有Unicode字符现在几乎找不到理由不用它。第二部分是基础数据。我把系统的默认管理员账号、角色数据、菜单数据、院系数据、课程类型字典这几类基础数据全部写好INSERT语句。这些数据为什么必须在SQL脚本里默认带上原因很简单如果让用户通过页面手动录入这些基础数据整个系统的首次启动体验会非常糟糕——登录后什么功能都点不了因为角色、菜单全都没配。把基础数据以脚本的形式提供系统一启动就是一个可以完整演示的状态这对毕业设计答辩来说特别重要。第三部分是测试数据。我生成了一部分模拟的教师数据和工作量申报数据方便演示列表分页、报表统计这些功能。这里有个技巧在插入测试数据时我特意让workload_record表的时间字段分布在不同的月份和学期这样统计报表的曲线图才能展示出有变化的数据形态而不是一条平平的直线。3. 实操过程与核心模块实现3.1 登录鉴权全流程从JWT生成到拦截器校验登录鉴权是这个系统最基础也最重要的模块。我用的方案是JWTJSON Web Token登录成功后后端生成一个token返回给前端前端存储在localStorage中后续每次请求在请求头带上Authorization字段。这个方案不需要在服务端存储会话信息对前后端分离架构来说非常友好。具体实现流程是用户提交用户名密码后端先校验验证码如果有的话再通过MyBatis-Plus的QueryWrapper查询用户表。查到用户后用MD5加盐的方式比对密码密码正确就生成JWTtoken中包含用户ID和角色编码过期时间设置24小时。同时把用户信息和权限列表缓存到Redis中方便后续接口鉴权时快速查询。拦截器这部分我写了一个定义的拦截器来验证token。在preHandle方法中从请求头中取出token解析并验证签名然后从Redis中获取用户权限列表判断当前请求的URL是否在权限范围内。这里给出一个典型的实现思路public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (StringUtils.isBlank(token)) { // 未登录返回401 response.setStatus(401); return false; } try { Claims claims JwtUtil.parseToken(token); String userId claims.getSubject(); User user userService.getById(userId); if (user null) { response.setStatus(401); return false; } // 校验权限——如果是需要权限的请求检查当前用户是否有该URL的访问权限 if (handler instanceof HandlerMethod) { HandlerMethod handlerMethod (HandlerMethod) handler; // 检查是否有RequiresPermission注解 RequiresPermission perm handlerMethod.getMethodAnnotation(RequiresPermission.class); if (perm ! null) { // 从用户缓存中获取角色列表与权限标识判断是否匹配 } } request.setAttribute(userId, userId); return true; } catch (Exception e) { response.setStatus(401); return false; } }这段代码里有一个核心设计拦截器不做业务逻辑判断只做基础校验和权限判定。业务异常一律在Controller中通过抛出统一业务异常的方式处理。因为有些操作的权限判断不是简单的URL匹配能解决的比如“教师只能撤回自己提交的申报单”这种场景必须在业务层判断当前登录用户的ID和数据里的申报人ID是否一致。3.2 工作量申报与多级审核流程的实现工作量申报模块是整个系统的业务核心它的流程是教师填写申报单选择类型、填写工作量描述、填写数值、上传附件→ 提交后进入待审核状态 → 教研室主任初审 → 院系管理员复核 → 教务处终审 → 通过或退回。退回的申报单可以修改后重新提交再次进入审核流程。数据库层面workload_record表设有一个status字段用数字表示状态0表示草稿、1表示待教研室审核、2表示待院系审核、3表示待教务处审核、4表示已通过、-1表示已退回。审核表workload_audit记录每一步操作包括审核人ID、审核意见、审核时间、操作类型。两条核心代码如下提交申报的Service方法需要创建一个申报记录并设置初始状态为待教研室审核public void submitWorkload(WorkloadRecord record, Long userId) { record.setTeacherId(userId); record.setStatus(1); record.setCreateTime(new Date()); // 校验工作量数值大于0类型必填 workloadRecordMapper.insert(record); // 记录一条初始提交日志 WorkloadAudit audit new WorkloadAudit(); audit.setRecordId(record.getId()); audit.setOperatorId(userId); audit.setAction(submit); audit.setOpinion(提交申报); audit.setCreateTime(new Date()); workloadAuditMapper.insert(audit); }审核通过的Service方法需要根据当前记录的status判断审核人的角色然后流转到下一个状态public void approveWorkload(Long recordId, Long auditorId, String opinion) { WorkloadRecord record workloadRecordMapper.selectById(recordId); if (record null) { throw new BusinessException(申报记录不存在); } if (record.getStatus() 4) { throw new BusinessException(该记录已终审通过不可重复操作); } // 根据当前状态推进到下一个审核节点 int nextStatus record.getStatus() 1; record.setStatus(nextStatus); workloadRecordMapper.updateById(record); // 写入审核日志 WorkloadAudit audit new WorkloadAudit(); audit.setRecordId(recordId); audit.setOperatorId(auditorId); audit.setAction(approve); audit.setOpinion(opinion); audit.setCreateTime(new Date()); workloadAuditMapper.insert(audit); }这里有个需要特别说明的设计为什么用状态机逐步流转而不是直接记录一个“当前审核人”字段因为你必须保证每一步审核都是由正确的角色完成的——教研室主任只能操作状态为“待教研室审核”的记录院系管理员只能操作状态为“待院系审核”的记录。如果在业务代码里判断当前登录用户的角色和记录的状态就可以天然地限制操作权限不需要额外写复杂的权限规则。退回操作同样如此但退回的目标状态会有区别如果退回给修改人需要把状态变为-1让申报人看到“已退回”并可以编辑后重新提交还有一种需求是退回到上一级即终审不通过退回到院系审核状态。这两种退法在实现上就相差一个目标状态值的设置但业务含义完全不同这也是我在接口文档中单独说明的重点。3.3 统计报表用一条SQL实现多维汇总统计报表这个模块是系统展示阶段的亮点。我实现了三个维度的统计按学期统计全院总工作量、按院系统计各院系的平均工作量、按个人统计某位教师的工作量构成。前两个在ECharts的柱状图里展示第三个用饼图展示教学、科研、社会服务三类工作量的占比。后端接口的核心逻辑就是一条动态拼接的SQL。比如按院系统计工作量的SQLSELECT d.dept_name AS deptName, SUM(w.workload_value) AS totalWorkload, COUNT(DISTINCT w.teacher_id) AS teacherCount FROM workload_record w INNER JOIN teacher_info t ON w.teacher_id t.id INNER JOIN dept_info d ON t.dept_id d.id WHERE w.status 4 AND w.create_time BETWEEN #{startDate} AND #{endDate} GROUP BY d.dept_id ORDER BY totalWorkload DESC这条SQL的核心价值在于把技术难度最大的部分放到了数据库层面解决后端只需要接收起止时间参数返回结果集前端拿到数据后直接绑定到ECharts。复杂报表虽然看起来高大上但在这种规模的项目里一条经过优化的SQL往往比花哨的设计更实用。报表接口的性能优化方面我给workload_record表加了联合索引索引字段是(status, teacher_id, create_time)。这个索引能覆盖大部分查询场景——按教师查自己的记录时用到teacher_id按状态筛选时用到status按时间范围统计时用到create_time。如果这条查询在数据量大了之后变慢优先考虑调整索引而不是在代码层做逻辑判断。3.4 接口文档与Swagger的配置要点接口文档是毕设答辩时老师一定会问的部分如果拿出一个Swagger页面现场演示效果会非常加分。我在项目中集成的是springfox的Swagger 2.9.2版本。为什么强调版本因为Swagger和SpringBoot的版本兼容问题真的很容易踩坑尤其是SpringBoot 2.6.x之后路径匹配策略改了默认的PathMatchStrategy从AntPathMatcher变成了PathPatternParser这两者的不同会直接导致Swagger在启动时抛出异常。如果用了SpringBoot 2.6及以上版本需要在application.yml中添加一行配置来兼容spring: mvc: pathmatch: matching-strategy: ant_path_matcher另外要重点在Controller和实体类上写清楚注解。Controller的方法上加上ApiOperation注解描述方法功能参数上加上ApiParam注解描述参数含义实体类上加上ApiModelProperty注解描述字段含义。这些注解必须在写代码的时候就顺手加上不要等项目做完了再补——虽然补注解不费太多工作量但只要一拖延就再也提不起补的劲了。4. 常见问题与排查技巧实录4.1 前后端联调阶段最容易踩的坑前后端联调是这类项目里出错率最高的阶段而绝大多数问题都集中在跨域和请求格式这两个点上。跨域问题就是前端项目运行在8080端口后端项目运行在9090端口前端发给后端的请求被浏览器拦截了。解决办法是后端配置一个全局跨域过滤器允许来自前端地址的请求访问。配置很简单关键是理解了为什么需要这一步操作——浏览器的同源策略是安全机制但我们的开发场景需要跨域请求所以必须显式声明允许。请求格式问题更隐蔽也更容易忽略。前端用axios传POST参数时如果直接传一个对象axios默认会把它序列化成JSON格式放在请求体里但后端的Controller如果接收的参数是QueryString格式就会返回参数不匹配的错。解决办法是统一约定POST请求一律在axios中设置Content-Type为application/json后端用RequestBody配合对象接收如果是文件上传则用FormData格式。还有一个常见问题是日期格式化。前端传的日期是“2024-12-01”这种格式后端的实体类里如果用的是Date类型Spring需要配置全局日期格式转换器不然会解析失败。我在项目中写了一个配置类统一处理了String转Date的格式避免了每个接口都要单独处理的麻烦。4.2 SQL脚本导入时需要注意的细节拿到SQL脚本后导入失败是最常见的事而失败的原因往往不是SQL语句写错了而是环境问题。第一种情况是MySQL版本不一致。MySQL 5.7和MySQL 8.0的很多语法和默认行为不一样比如在MySQL 8.0中如果生成的用户表时间字段设置了默认值可能会报错因为默认值表达式不能包含当前时间戳等限制。我的建议是本机装MySQL 8.0版本和项目脚本保持同一版本导入流程最顺。安装的时候把编码格式选成utf8mb4这是很多同学最容易忽视的环节——数据库编码不对所有中文字段都会出现乱码。第二种情况是导入顺序问题。如果SQL脚本中有外键约束先导出的表就可能导致导入失败。我一般把建表语句中的外键约束都去掉把外键关系的维护放到应用程序层处理这样既能减少导入时的问题也让表结构的维护更加灵活。第三种情况是安全模式限制。MySQL默认开启了safe-update模式执行不带WHERE条件的UPDATE或DELETE语句会直接报错。如果在执行脚本中某些数据清理语句时报错执行SET SQL_SAFE_UPDATES 0;即可关闭该限制完成后记得改回来。4.3 SpringBoot版本和环境匹配问题版本兼容性是新手最容易栽跟头的地方。我建议直接锁定SpringBoot 2.7.x系列这个版本既保留了2.x时代的稳定性又兼容了大部分第三方库的最新版本。搭配JDK 1.8这是最经典、资料最多的组合几乎不会遇到环境层面的冷门问题。如果选了SpringBoot 3.x就意味着必须使用JDK 17或以上MyBatis-Plus要升级到3.5.3以上的版本Swagger要换成springdoc这一套新的库。技术升级本身不是坏事但对毕业设计来说稳定压倒一切。别在答辩前一天还在解决依赖冲突的问题。另外前端Node版本也需要注意。Vue 2项目一般建议使用Node 14或者16的LTS版本太高版本的Node可能导致node-sass编译出错。如果你项目中用到了node-sass建议换成sass也就是dart-sass这样Node版本兼容性好得多。这是我实际踩过的坑——Windows上node-sass的编译失败率实在太高了。5. 项目部署与展示建议5.1 从开发环境到打包部署的完整路径项目写完之后部署演示环节也能体现出你的完整工程能力。后端打包直接用Maven命令在项目根目录执行mvn clean package -DskipTests就能在target目录下生成一个可以直接运行的jar包。执行java -jar xxx.jar --server.port9090 就能启动后端服务。前端需要先构建静态文件在Vue项目根目录执行npm run build生成一个dist目录。有两种部署方式一种是把dist目录里的文件复制到Nginx的html目录下配置Nginx监听8080端口并设置反向代理前端请求的接口地址都代理到后端的9090端口另一种更简单的做法是直接把dist目录放在后端项目的src/main/resources/static目录下这样SpringBoot启动后既可以提供接口服务也可以直接访问前端页面一个进程搞定所有事情。我推荐使用Nginx方式因为这才符合前后端分离架构的常规部署形态。Nginx配置中这一段很关键server { listen 8080; server_name localhost; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://localhost:9090/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }其中try_files的作用非常关键前端路由使用history模式时刷新页面会向服务器发起真实请求如果没有这一条匹配规则直接刷新二级页面就会出现404这个问题在微信环境里一旦遇到就非常明显。5.2 演示数据和Demo账号的准备演示环节的准备往往被忽略但实际效果差异很大。在部署环境里一定要准备好一套可以直接演示的数据包括不同角色的账号一个教务处管理员、一个院系管理员、一个教研室主任、两个普通教师。账号密码最好在答辩前打印在一张纸上到时候可以直接登录演示而不是在评委面前临时注册账号。我特意在SQL初始化脚本里设计了几个不同特点的教师账号一个教师的工作量数据非常全教学、科研、社会服务三类都有记录适合展示个人统计饼图一个教师的数据集中在校内教学适合和其他教师形成对比还设计了一条待审核的数据方便现场演示审核流程的完整操作。数据设计这个细节比很多人想象得要重要得多——一个丰富的数据集能让评委在短时间内理解你的系统能做什么这比口头解释十句话都有效。6. 项目后续扩展方向系统基础功能完成后有两个扩展方向我认为很值得提一下。第一个是工作量导入功能现在很多高校的工作量数据是从教务系统导出的Excel文件里批量读取的当前系统是纯手工录入如果加上Excel导入可以解决实际使用中的效率问题。后端可以用EasyExcel这个库解析Excel文件前端用Element UI的Upload组件上传文件整个实现不算复杂但对系统的应用价值提升非常明显。第二个方向是通知提醒功能。当审核结果发生变化时系统应该能通知到相关教师。如果只是做一个站内信功能在后端增加一张通知表在审核方法中写入一条通知记录前端在页面顶部加一个铃铛图标轮询未读通知一两天的时间就能做完。如果想让系统更接近生产环境可以接入邮件通知——用Spring的JavaMailSender在审核通过时自动发邮件整个功能也不超过半天的工作量。项目做完之后我个人的体会是这种管理系统类的项目的技术难点从来不在某个单独的技术点上而在如何把一堆零散的业务需求抽象成清晰的数据模型和接口设计。这个能力只有在真实动手做项目的过程中才能慢慢培养起来。如果你正在做类似的毕设项目我建议不要只停留在把功能跑通的层面多问问自己为什么这样设计表结构、为什么这样设计接口这些追问才是项目对你最大的价值。