1. 先聊聊这个项目解决的到底是啥问题做教师教学培训管理系统之前我在学校里转过一圈发现一个非常典型的现状培训通知靠微信群接龙报名统计靠Excel来回合并签到靠纸笔学时台账在年底汇总时能把教务老师逼疯。不同科室各存一份表数据口径对不上问起来就是我们这边明明报了三十个人。这个项目本质上就是把这一整条线搬到线上培训项目统一发布、教师在线报名、管理员审批、签到记录自动累计学时、学期末一键导出统计报表。从技术角度看这是一套典型的Java全栈管理系统后端以SpringBoot为骨架前端用Vue数据库用MySQL整体走前后端分离模式。它解决的不仅是有没有用的问题更关键的是把分散在Excel、纸质签到表、微信群里的数据统一收口让每一场培训都能追溯谁发布了、谁报名了、谁参训了、得了多少学时、效果评价如何。这套逻辑放到很多场景都成立企业内部的员工培训、行业学会的继续教育、医院规培管理换个表名和字段就能复用属于做完一个能理解一类项目的典型选题。适合谁看呢第一类是想选毕业设计题目的计算机相关学生第二类是刚接触SpringBoot、想找一个完整CRUD加报表导出练手项目的初级开发者第三类是学校里或培训机构里真准备做信息化改造、但预算有限只能自己搭的老师。三类人的诉求不一样但都能从这套系统的设计思路里拿到自己能用的东西。1.1 从痛点出发为什么需要这样一套系统先别急着想数据库表把业务跑一遍你才知道哪些字段不能少。我记得第一次做需求调研时教务老师提了一句话我就想知道这学期每个老师参加了几次培训、一共多少学时、哪个学院参加得最少。就这一句话直接决定了整个系统的核心培训项目 报名记录 参训记录 学时汇总四件事。再把场景扩展一下完整的业务链条是这样的管理员发起培训项目填写培训主题、类型新教师岗前培训、教学能力提升、信息化专项、师德专题等、主讲人、时间地点、学时数、名额上限。教师在系统里看到培训列表选择报名。如果超过截止时间或名额满了报名入口关闭。管理员审批报名通过后教师按时间参训现场扫码或签到确认。培训结束后教师可以提交评价管理员补录或者系统自动生成参训记录并累加学时。学期或年度末按学院、个人、培训类型三个维度统计学时完成情况、覆盖率、人均参训次数导出Excel。这里有个容易忽视的点学时不是报名就算的必须以签到或审批后的参训记录为准。很多初版系统把报名记录直接当成学时依据结果教师报了名不来学时照样记上业务部门一核对就出问题。所以我会在设计里把报名表registration和参训记录表record分开报名通过只是拿到了入场资格真正计学时靠的是参训记录。这套区分在后面对接统计报表时省了很大的事。1.2 技术选型的取舍为什么是SpringBoot Vue这个项目为什么选择SpringBoot而不是其他方案我在选型时有两个核心考虑生态和岗需。先说生态。教师培训管理系统本质上是一个标准的信息管理系统需要的技术栈是Web框架、ORM、权限认证、报表导出、前端界面。SpringBoot在这条路上基本是毕业即就业的主流答案自动配置省掉了大量XML配置内嵌Tomcat让部署变成一个java -jar命令配合MyBatis-Plus这种增强插件单表CRUD甚至不用写SQLSpring Security或者Sa-Token解决登录鉴权Apache POI处理导出。这一整套方案在网上有大量成熟案例万一踩坑搜索一下基本都能找到答案。再考虑数据规模和并发。一所高校的教师数量大概在一千到五千人培训项目一个学期几十场报名记录可能过万。这个量级用MySQL完全扛得住不需要引入Redis做缓存更不需要微服务那套注册中心、网关、配置中心的复杂架构。我见过不少毕设或小项目为追求高大上硬上一套Spring Cloud结果光服务拆分和链路排查就把人折腾够呛业务却只有三张表。技术选型不是越新越重越好而是要匹配真实负载。这套系统里SpringBoot单体应用 合理索引 缓存可行性评估就已经能覆盖上线后三五年的数据增长。前端选Vue是当前前后端分离的主流搭配但如果你是自己一个人做不熟悉Vue也没关系可以直接用服务端渲染方式SpringBoot提供Thymeleaf模板业务上完全成立。我之前做这个项目时选了Vue Element UI原因只有一个表格表单组件成熟管理后台界面几乎不用自己造轮子。这个决定可以从第2章的数据结构继续展开。2. 系统设计落地数据库、接口与权限模型这一章是最有技术含金量的部分。很多刚上手的人喜欢上来就建表我觉得顺序应该反过来先画出业务流转图再根据流转表定表最后才写字段。下面把我实际用过的表结构设计、接口约定和权限模型分别说清楚这些都是可以直接抄作业的。2.1 数据库表设计我踩过的最重要的几个坑先给一份核心表清单五张业务表加三张基础表表名作用关键字段sys_user登录账号username, password, role, statusteacher_info教师档案user_id, name, college, title, phonetraining_project培训项目name, type, teacher, hours, limit_count, begin_time, end_time, statustraining_registration报名记录project_id, teacher_id, audit_status, audit_timetraining_record参训记录registration_id, project_id, teacher_id, hours, sign_in_time, sourcetraining_evaluation培训评价project_id, teacher_id, score, commentsys_role角色表role_code, role_namesys_menu菜单/权限表parent_id, name, perms这里有几个坑值得提醒。第一个坑用户表千万不能只存姓名。教师培训系统里登录用户是教师但统计要按学院、职称、入职年份分组所以至少要把teacher_info拆出来和sys_user做一对一关联。如果你把姓名、学院、职称全塞进user表后期做按学院统计参训率就只能在user表上加一堆业务字段表职责混乱维护久了必炸。实际做的时候我还在teacher_info里加了entry_date入职时间和teacher_no工号因为很多培训项目对新教师和骨干教师有不同要求这些字段在筛选和统计时都会用到。第二个坑唯一索引比代码校验更可靠。防重复报名最稳妥的是在training_registration表上加联合唯一索引(project_id, teacher_id)同时在Service层写一遍查重逻辑。索引是兜底代码逻辑是用户体验。并发场景下两个人同时点击报名代码查重可能都查到未报名然后都写了insert唯一索引会直接拒绝掉第二个请求这样才能保证数据不重复。ALTER TABLE training_registration ADD UNIQUE KEY uk_project_teacher (project_id, teacher_id);第三个坑参训记录的学时来源。培训系统里学时数可能来自几个不同渠道项目预设学时、管理员手动调整、补录历史数据。如果只在training_record里放一个hours字段以后追溯时不知道这个数是谁定的。我习惯加上source字段取值AUTO按项目默认学时、ADMIN_EDIT管理员修改、IMPORT历史数据导入。后面做统计报表时如果发现某个学院学时异常直接按source筛一遍就能定位原因。第四个坑状态字段用int还是varchar。我见过有人用int 0、1、2表示审批状态代码里写注释说明时间一长注释丢了看到0都不知道是待审核还是已拒绝。我最后统一用varchar存状态枚举比如PENDING、PASSED、REJECTED虽然多占几个字节但是代码可读性、日志排查、接口传输都友好得多。甚至可以直接把枚举类名作为常量映射前后端约定用同一个词。2.2 接口设计与前后端约定接口设计上我建议按资源划分统一以/api开头admin相关的路径加/admin教师端不加。当初定义的几组核心接口如下POST /api/auth/login 登录返回token GET /api/user/project/list 教师端分页查询培训项目 POST /api/user/registration 教师提交报名 GET /api/user/mine/records 教师查看自己的参训记录和累计学时 POST /api/admin/project 管理员创建培训项目 PUT /api/admin/project/{id} 编辑项目 POST /api/admin/audit/{id} 审批报名通过/拒绝 GET /api/admin/statistics 统计报表按学院/按时间 GET /api/admin/export 导出Excel前后端分离模式下接口约定比接口本身更重要。我这里说几个实际工作中的教训统一返回结构。无论成功失败都给前端一个固定JSON格式{ code: 200, message: success, data: {} }code用200表示成功非200表示失败前端只需判断code。业务异常在全局异常处理器里统一捕获转换成对应的code不要让Spring Boot默认的错误页直接抛给前端。分页参数统一。我用的格式是pageNum从1开始、pageSize默认10返回给前端的是MyBatis-Plus的IPage对象{records, total, pages, current}。前端表格组件直接绑字段后端不用为每个列表接口单独定制返回格式。时间格式统一。这是一个高频踩坑点。后端LocalDateTime如果直接序列化前端拿到的是2024-05-12T09:30:00这种带T的字符串Element UI的日期组件显示起来很别扭。我在application.yml里加统一配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8这样所有接口的时间字段统一输出成人类可读格式省掉前端一堆转换代码。2.3 权限模型别把权限写死在代码里教师培训系统的角色其实比较简单ADMIN和TEACHER如果再细分可以有教务管理员负责培训发布的TRAINING_MANAGER和院系管理员。我建议用经典的RBAC基于角色的访问控制不需要引入太复杂的安全框架直接用拦截器或过滤器校验角色即可。具体做法是登录成功时后端签发JWTtoken里带上用户id和角色编码前端把token存在localStorage或pinia里。请求时放在Authorization: Bearer token请求头中。后端写一个JWT拦截器统一解析token把用户信息放入ThreadLocal或请求上下文。public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { // 放行登录接口和部分公开接口在配置类里用excludePathPatterns控制 String token request.getHeader(Authorization); if (StringUtils.hasText(token) token.startsWith(Bearer )) { token token.substring(7); Claims claims JwtUtil.parseToken(token); if (claims ! null) { request.setAttribute(userId, claims.get(userId)); request.setAttribute(role, claims.get(role)); return true; } } response.setStatus(401); return false; } }拦截器里只校验token合法性和角色不把具体某个接口的权限写在Controller里。因为角色只有两三种靠注解RequireRole(ADMIN)就能控制但如果你预计角色会膨胀比如要加院系审核员再引入Sa-Token的权限框架或自定义PreAuthorize注解都不迟。当前这个项目规模下拦截器是最简洁、最不容易出错的方案。3. 核心模块实现报名、审批、统计这条主线系统设计完之后真正干活儿的部分来了。我按照业务主链路挑三个难点详细说一下JWT认证的落地细节、并发场景下的报名与审批逻辑、以及POI导出统计表。这三个部分几乎覆盖了面试官最喜欢追问的问题也是你把这个项目写进简历时最值得展开的点。3.1 认证模块JWT其实没那么玄登录接口的核心逻辑就是查用户、校验密码、发token三步。PostMapping(/login) public ResultLoginVO login(RequestBody LoginDTO dto) { // 1. 校验用户名是否存在 User user userService.lambdaQuery() .eq(User::getUsername, dto.getUsername()) .one(); if (user null) { return Result.error(用户不存在); } // 2. 校验密码注意密码不能明文存BCrypt加密 if (!BCrypt.checkpw(dto.getPassword(), user.getPassword())) { return Result.error(密码错误); } // 3. 检查账号是否被禁用 if (user.getStatus() 0) { return Result.error(账号已被停用请联系管理员); } // 4. 生成token有效期我设的是24小时 MapString, Object claims new HashMap(); claims.put(userId, user.getId()); claims.put(role, user.getRole()); String token JwtUtil.generateToken(claims, 24 * 60 * 60 * 1000); return Result.ok(new LoginVO(token, user.getRole(), user.getName())); }密码存储我统一用BCrypt而不是MD5。原因不多讲MD5加盐虽然也能用但BCrypt是自适应哈希抗暴力破解能力更强Spring Security里自带这个工具类引入成本几乎为零。这个细节你在面试时提一嘴会显得有安全意识。JWT的有效期是个值得说道的细节。一天过期够用吗如果寒暑假期间长期不用token过期后前端要跳回登录页体验不好。我的做法是token有效期7天但里面存一个lastActive时间拦截器每次解析token时检查如果超过一天没活跃就返回一个特殊错误码code: 40101前端收到后自动跳登录。这么做比设置极短有效期强制用户频繁登录体验好也比不做任何处理更安全。3.2 报名与审批唯一索引和状态机的配合报名接口看起来简单就是往registration表插一条记录但加上业务约束后就没那么随意了。我梳理出的约束条件有四个项目必须处于OPEN报名中状态当前时间必须在报名起止时间之间该教师没有被审批拒绝过且没有已参加的记录如果设置了名额上限已通过人数不能超过limit_count。前三个条件在Service里逐条校验第四个条件要小心处理。如果直接查count再判断是否小于limit并发下会出现超额100个名额第101和102个人同时查到100然后都写入了。我的解决方案是报名阶段不锁名额只保证不重复报名审批阶段由管理员逐条处理超员的项目管理员在审批时能看得到当前通过人数手动拒绝多余报名。对于教师的教务管理员来说这个操作习惯比系统的自动沙盒更符合实际——他们更信任自己点一下通过/拒绝的过程。审批接口的本质是一个状态流转待审核(PENDING) - 通过(PASSED) 待审核(PENDING) - 拒绝(REJECTED)管理员审批通过后我的代码同时会在training_record里插入一条待参训记录学时先按项目预设hours写入但标记为NOT_SIGNED。等培训当天实际签到后再把状态改成SIGNED学时正式生效。这样做的原因是报名通过但人没来的情况很常见学时不能提前计入。签到的方式我建议用最简单的管理员按名单勾选扫描二维码的方案涉及微信小程序或专用设备明显超出这个项目的主线了而且还要处理二维码过期、代签等各种边界非必要不引入。3.3 学时统计与导出POI的正确打开方式统计这块是系统里最直观体现价值的功能。学期末教务老师打开页面选择学年学期点击导出一份按学院汇总的Excel立刻生成。当年手工汇总要花两三天的活儿这里只要三秒钟。统计SQL的核心就是分组聚合SELECT t.college, t.title, COUNT(DISTINCT tr.teacher_id) AS trained_teacher_count, SUM(CASE WHEN tr.sign_status SIGNED THEN tr.hours ELSE 0 END) AS total_hours FROM training_record tr LEFT JOIN teacher_info t ON tr.teacher_id t.id WHERE tr.year #{year} AND tr.semester #{semester} AND tr.sign_status SIGNED GROUP BY t.college, t.title这里有个细节分组字段和查询字段必须保持一致trained_teacher_count是去重后的参训人数total_hours是总学时。同一个教师参加多场培训在记录表里有多行统计人数时不能直接count行数。这个坑我踩过表格里人数虚高一倍最后排查发现是没加DISTINCT。导出Excel我用的是Apache POI的EasyExcel方案。准确说对于简单的数据导出我推荐阿里巴巴的EasyExcel而不是原生POI。原因很简单原生POI写一个带样式的Excel需要手动创建CellStyle、设置字体、调整列宽代码量大且容易内存溢出EasyExcel基于注解几行代码搞定。Data HeadStyle(horizontalAlign HorizontalAlignEnum.CENTER) ContentRowHeight(20) HeadRowHeight(24) public class TrainingStatRow { ExcelProperty(学院) private String college; ExcelProperty(职称) private String title; ExcelProperty(参训人数) private Integer trainedCount; ExcelProperty(总学时) private BigDecimal totalHours; }然后导出接口就变得非常清爽GetMapping(/export) public void export(HttpServletResponse response) throws IOException { ListTrainingStatRow rows trainingRecordMapper.selectStatRows(year, semester); response.setContentType(application/vnd.openxmlformats-officedocument.spreadsheetml.sheet); response.setCharacterEncoding(UTF-8); String fileName URLEncoder.encode(year 年学期培训统计, UTF-8); response.setHeader(Content-Disposition, attachment;filename*UTF-8 fileName .xlsx); EasyExcel.write(response.getOutputStream(), TrainingStatRow.class) .sheet(培训统计) .doWrite(rows); }注意导出文件名的处理这个细节能劝退一大批人如果用response.setHeader直接设置中文文件名容易在跨浏览器时乱码统一用URLEncoder.encodefilename*UTF-8的方式最稳。有个热词是java poi word能生成图表吗这里顺便把我的经验说透。POI确实可以从Word的XWPFDocument里插入图表Chart但API非常有限只能做柱状图折线图样式调整也很受限制。真需要生成带图表的培训分析报告Word文档我的做法是提前用Word做一个带书签的模板后端用POI填充文字内容图表部分直接在模板里手工排好需要更新数据时用契约把图表的数据源区域替换掉。比纯代码生成图表可靠得多。4. 常见问题排查与优化实录开发过程中踩的坑不少这里挑几个最具代表性的问题写出来每一个都是我真实遇到并排查过的。4.1 开发期的高频Bug乱码、跨域和日期序列化中文乱码准确说是MySQL插入中文不乱码但查询条件带中文返回不了数据。问题几乎都出在JDBC连接串。我用的连接串是jdbc:mysql://localhost:3306/training_system? useUnicodetruecharacterEncodingUTF-8serverTimezoneAsia/ShanghaicharacterEncodingUTF-8必须显式加上只靠MySQL默认字符集有时会继承到latin1。另外创建表时尽量统一用utf8mb4能存emoji和特殊字符排序规则选utf8mb4_general_ci或者更严格的utf8mb4_unicode_ci。这里敲一下重点如果表已经建好ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4;可以改但已有数据的表转换时要小心最好先在测试库试。跨域问题前后端分离项目的标配坑。开发时前端跑在localhost:5173后端跑在8080如果不配置跨域浏览器直接拦截。Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }生产环境我建议去掉allowedOriginPatterns(*)改为Nginx代理让前端请求走同域路径/apiNginx把请求转发到后端服务这样前端根本不用关心跨域后端也更安全。日期序列化问题前面提过这里再补一个如果返回的是Date而不是LocalDateTimetime-zone: GMT8配置不一定生效需要检查Jackson的使用类型。我后来统一用LocalDateTime配合JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8)注解兜底不管全局配置怎么变字段级注解最强。4.2 性能与并发数据量起来以后怎么办教师培训系统理论上并发不会太高全校同时登录的峰值一般在开学初培训通知发布后的一两个小时。但既然你把这个项目写进简历最好能说出点性能优化的思路免得面试官觉得你只会CRUD。我的优化思路按优先级排索引优化。报名表建立在project_id、teacher_id上的联合索引是必须的参训记录表year semester建立索引统计查询从全表扫描变成索引范围扫描。用EXPLAIN看执行计划时如果出现了Using filesort或Using temporary多半是索引没设计好调整group by或order by字段的索引组合就行。分页查询的深翻页问题。列表页如果用户翻到第100页MyBatis-Plus底层是LIMIT 990, 10数据量大时会越来越慢。优化方式有两个一是前端限制只能查询前100页二是用延迟关联方式分页先只查主键再回表取详细数据。// 延迟关联示例 SELECT r.* FROM training_record r INNER JOIN ( SELECT id FROM training_record WHERE year #{year} ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} ) tmp ON r.id tmp.id缓存。培训项目列表这种读多写少的数据在项目发布后短时间内会被大量刷新我加了Spring Cache的Cacheable注解缓存5分钟有效降低数据库压力。教师个人信息则用CachePut在更新时刷新缓存。这个量级没必要上RedisCaffeine本地缓存足够注意集群部署时本地缓存不能共享但目前这套系统单节点部署完全没问题。4.3 部署上线从Jar包到Docker部署方案我给过两套传统方案和容器方案。传统方案最简单服务器装JDK把项目打成Jar包mvn clean package -DskipTests nohup java -jar training-system.jar --spring.profiles.activeprod log.out 21 nohup加重定向把日志输出到文件。生产环境一定要指定profile区分开发库和生产库我在这上面吃过亏差点把测试数据清掉。容器方案用Docker-compose一起编排后端、前端和MySQL这是当前中小项目的主流方式。Dockerfile就几行FROM openjdk:17-jdk-slim WORKDIR /app COPY target/training-system.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -Xms256m, -Xmx512m, -jar, app.jar]这里特别注意内存参数。云服务器如果只有2G内存JVM默认堆大小可能占掉服务器一大半加上MySQL直接内存耗尽。我建议JVM堆设256m起步、512m封顶配合-XX:UseG1GC。.env文件里再定义MySQL密码、数据库名等环境变量docker-compose起来以后整个系统一条命令搞定。Nginx做前端静态资源托管和反向代理时关键配置就一段server { listen 80; server_name training.example.com; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://backend:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files这行是Vue前端history路由的核心刷新页面时如果Nginx找不到对应路径就会返回到index.html交给前端路由处理。5. 最后分享点实在的经验如果你正在准备做类似的系统我个人有几点体会供参考。第一先跑通主链路再补细节。我的开发顺序是登录 - 项目发布 - 报名 - 审批 - 参训记录 - 统计导出六步走通以后系统已经能交付给教务使用。之后再慢慢加评价、消息通知、教师档案导入这些功能。千万别一上来就抠UI管理后台的业务人员对界面要求远低于对流程闭环的要求。第二数据字典能救你后半程的命。培训类型、审批状态、报名状态这些字段在一个系统里会有多个模块使用。我用了一张sys_dict表存所有字典项前端通过接口拉取下拉选项后端也可以统一从DictUtil工具类读取。这样改动字典数据不需要发版比在代码里写死枚举更灵活。如果不想建字典表那至少要把枚举常量单独放在一个类或enum里千万不能散落在各处魔法字符串。第三不要忽略日志。刚开始我图省事Service里只在异常时打日志结果有一次管理员说我明明审核通过了为什么教师看不到后台一查log发现教师端列表接口的SQL有个条件过滤了状态根本没查出来。后来我在所有关键操作创建项目、报名、审批、导出里都加了一条info日志记录操作人、操作时间和业务主键。排查问题从猜变成看日志定位效率高了一个数量级。这个系统做完以后整个培训管理的流程肉眼可见地顺了很多。对我个人而言最大的收获不是代码量而是明白了一个道理大部分业务系统到最后拼的不是框架多新而是对业务细节的理解和数据流的梳理。这套设计思路迁移到企业培训、课程报名、甚至会议管理都能用。你要做的就是拿这个项目把SpringBoot的常用开发模式练熟把从需求到上线整套流程跑通面试时能讲清楚每个设计为什么这么做就已经赢过一大半同类项目了。