企业官网建设流程全解析

每年到了毕设季，总有人拿着“Java培训班管理系统”这个题目来找我。说实话，这题目在计算机毕设里出镜率极高，但大部分同学做出来的东西只是CRUD堆砌，答辩时一问逻辑就露馅。我这篇文章就把我当时做这个题目的完整思路、技术选型、数据库设计和踩坑过程重新梳理一遍，希望能让正在为这个题目头疼的人少走一点弯路。

先说明一下，这个系统核心要解决的场景是：一个做培训的机构（Java培训、考研培训、少儿编程都可以）需要把学员、班级、课程、教师、报名、缴费、考勤、报表这些事管起来。用Java做后台，用MySQL存数据，通过浏览器访问操作。如果你是计算机科学与技术、软件工程等相关专业，想选一个既能写清楚又不会做不完的毕设，这个题目是非常合适的——因为它业务足够具体，功能边界清晰，技术栈又有充分的发挥空间。

1. 选这个题目之前，先想明白培训班管理系统到底在管什么

1.1 先画出业务边界，别一上来就写代码

很多同学做管理系统最大的问题，是上来就用Spring Boot生成一套增删改查，然后去搞用户表、角色表、菜单表，最后发现整个系统不知道该干嘛。这是典型的需求倒置。正确的做法是先画业务全景图。培训班管理系统本质上要管理的资源就这五类：学员、教师、课程、班级、财务流水。围绕这五类资源发生的操作，就是报名、排课、上课、缴费、退费、统计。

你可以拿一张纸，把下面这几个核心流程画出来：

• 新学员来咨询：登记基本信息 -> 选择课程 -> 分配班级 -> 生成缴费单 -> 缴费成功 -> 正式入班。
• 学员开班后：每节课记录考勤 -> 自动生成课时消耗 -> 课程结束后可续报或结业。
• 教学过程中：管理员维护班级和课程，教师查看自己课表，学员查看自己课表和课时余额。
• 经营层面：按月统计营收、班级人数、退课率，支撑机构做决策。

把这个流程图画完，系统的功能模块就自然出来了。再进一步拆解成用户角色：管理员、教师、学员（有的系统还要加一个财务角色）。每个角色看到的内容和能做的操作完全不同。比如教师不需要看到整个机构的财务报表，学员也不应该进入班级管理页面。

1.2 角色和权限：没有需求分析，后面全是坑

我见过很多系统把管理员和教师的功能做成同一套，只是在菜单上隐藏了按钮，这其实是很危险的。因为你答辩的时候，老师大概率会问“教师这个角色能不能通过直接输入URL访问管理员的接口？”一旦你没有在后台做接口级权限控制，这个问题就直接暴露了。

所以需求阶段就要把所有角色允许的操作整理成一张表。我用我当时整理的部分内容给你参考：

不要小看这张表，它决定了你的数据库要怎么设计、接口要怎么写、前端菜单怎么渲染。说句实在话，毕设系统功能再多都不怕，最怕的是权限混乱。你把这个整理清楚，后面每个模块都围绕这个边界实现，基本已经及格了。

1.3 为什么Java技术栈特别适合这种题目

说到Java，很多同学第一反应是“环境配置麻烦”“生态太大不知道用哪个”。但恰恰是这个生态，让这类管理系统变得容易实现。招培训管理系统要用的：Web框架、ORM框架、模板引擎、前端UI库、权限拦截、事务管理，全都有成熟方案。比如Spring Boot自动配置帮你搞定大部分整合，MyBatis用注解或XML写SQL都很灵活，前端用Bootstrap或者Vue都能快速做出能看的界面。

更重要的是，Java在毕设答辩中是最“正统”的选择。大部分高校的计算机专业课程都以Java为主线，Java Web、Java EE、SSM框架都是课程内容，答辩时老师能问到你自己掌握的点上。比起用Python Flask或者Node.js，Java系的毕设更容易找到参考资料，也更容易解释清楚设计思路。哪怕你只是中等水平，只要框架结构清晰、关键查询逻辑说明白，拿个良好问题不大。

2. 技术选型：不是越新越好，关键是稳

2.1 三种常见方案对比

这个题目最常见的实现方案有三种，我分别说下适用场景：

我自己做的时候选的是Spring Boot + MyBatis + Thymeleaf + Bootstrap。没有用前后端分离，因为毕设要管的东西很多，前后端分离意味着你要维护两套代码，还要处理跨域、token、打包部署问题，时间成本不小。用Thymeleaf做服务端渲染，页面逻辑和Java代码在一个工程里，调试直观，答辩时也容易讲。

如果你有精力，也可以选择Spring Boot + Vue前后端分离，但这个适合你本身已经会Vue基础上手很快的情况。千万不要为了“技术新”而选自己完全不会的组合，毕设的核心是完整性，不是炫技。

2.2 项目结构怎么搭建

用Spring Boot建工程时，包结构很关键。我建议按模块分包，而不是按层分包。按层分包是controlller、service、mapper三个包下把所有类堆一起；按模块分包是模块名下面再分controller、service等。前者在项目小时无所谓，一旦功能多起来，找文件就费劲。

我当时的包结构是这样：

com.example.training ├── controller │ ├── AdminController.java │ ├── ClassesController.java │ ├── StudentController.java │ └── FinanceController.java ├── service │ ├── ClassesService.java │ ├── EnrollmentService.java │ └── FinanceService.java ├── mapper │ ├── ClassesMapper.java │ └── EnrollmentMapper.java ├── entity │ ├── Student.java │ ├── Classes.java │ ├── Course.java │ └── PaymentRecord.java ├── common │ ├── Result.java │ ├── PageResult.java │ └── GlobalExceptionHandler.java ├── config │ └── WebConfig.java └── interceptor └── AuthInterceptor.java

这种结构的好处是，entity里放数据库表对应的实体，common里放统一返回结果和全局异常处理，interceptor里放登录拦截器。答辩时老师问你“你这个项目的分层思想是什么”，你直接可以从包结构引出来讲：控制层只接收参数和返回结果，业务层处理具体规则，持久层只做数据读写。这就是标准的三层架构。

2.3 环境配置里最容易翻车的细节

Java环境配置看似简单，实际翻车率极高。我整理几个高频问题，都是我当时实测踩过的：

• JDK版本和Spring Boot版本要匹配。比如Spring Boot 2.7.X用JDK 8或11没问题，Spring Boot 3.X必须用JDK 17+。很多同学网上复制代码发现启动不了，一查就是版本不匹配。
• Maven依赖下载慢的问题。建议在settings.xml里配置阿里云镜像，不然一个spring-boot-starter-web下载半小时很正常。
• MySQL连接时区问题。连接串里一定要加上serverTimezone=Asia/Shanghai，否则半夜打开项目就会报时间异常。
• 端口被占用。本地用8080端口经常被各种程序抢，要么换端口，要么在application.yml里配置server.port=8088。

这些内容不需要你背下来，但要知道排查思路。如果真的启动报错，先看控制台最下面几行异常原因，不要只看第一行，因为第一行往往是Exception，具体原因在Caused by后面。

3. 数据库设计：这类系统的灵魂

3.1 核心表与关系

数据库设计对这个系统来说是最重要的一环。你后面所有功能的复杂度，其实在表设计阶段就定好了。培训班管理系统的核心无非就是：机构有多个班级，每个班级开在某门课程上，一个老师可以带多个班，一个学员可以报多个班，每次报名产生一张订单，订单对应缴费记录。在此基础上还有考勤记录，记录每个学员每节课的出勤状态。

我用表格给你列出主要表以及关键字段，你照着这个方向去建表基本不会跑偏：

注意几个关键点：金额字段用decimal，不要用float或double，否则金额计算会出现0.30000000000000004这种问题。日期字段用date或datetime，不要用字符串存，否则统计时会很痛苦。班级表和报名表之间是多对多的关系，通过enrollment中间表解耦。这个设计既符合第三范式，查询也够灵活。

3.2 表设计中容易踩的坑

上面那组表看起来简单，但有几个坑我特别想提一下。

第一个坑是全班共用一个登录账号。很多同学为了让登录简单，把学员姓名当用户名，密码字段随便存，结果一个学员毕业后，另一个学员用相同姓名登录就崩了。正确做法是把登录信息独立成user表，student表通过user_id关联。这样就算重名，账号依然是唯一的。

第二个坑是软删除。做管理系统时，数据删除不要用物理删除，特别是学员和报名记录。比如学员误操作退课了，如果直接delete掉报名记录，缴费数据就彻底没了，后续统计就会出错。我建议每张核心业务表都加一个status字段，用0表示正常，1表示禁用/退课/删除。查询时默认只查status=0的数据。这样即使出问题也能回溯。

第三个坑是班级剩余名额的计算。很多同学每次展示班级列表时，现算“capacity - enrolled”，查询量一大就会卡。正确做法是在classes表冗余一个enrolled字段，报名成功时+1，退课时-1，查询列表时直接取这个字段。虽然要维护一致性，但毕设数据量不大，维护成本远低于查询成本。

3.3 排课冲突与班级容量如何在表结构上预防

班级管理里最典型的业务问题，就是排课冲突和超容量报名。排课冲突指的是一个老师在同一时间段被分配到两个不同的班级上课。如果你的系统排课只是简单维护班级的start_date和end_date，没办法检测具体时间段。

我当时做了一个比较务实的设计：给班级表增加week_day和start_time、end_time字段。比如“Java就业班”安排在周二和周四的19:00-21:00。这样排课冲突的检测就变成了班级之间同一teacher_id和同一week_day及时间段是否有重叠。服务端在新增或修改班级时做一个校验，如果时间重叠就直接提示。这个逻辑放在数据库层用unique约束做不了，因为要判断重叠区间，只能放在service层用Java代码判断。具体的判断逻辑我后面在“模块实现”里讲。

班级容量上的预防很简单：enrollment表加一个唯一约束(student_id, class_id)，防止同一个人重复报名同一个班。同时在报名事务里检查enrolled < capacity，否则就抛出“该班名额已满”。这是最基础也是最重要的约束，不能只靠前端提示。

4. 从登录到核心业务：模块实现顺序与要点

4.1 登录与权限控制

登录模块我建议放在最前面做，因为后面所有模块都需要登录状态和角色信息。我用的方案是Session + 拦截器。

用户在登录页提交用户名密码，Service层校验通过后，把用户对象放到Session中。然后写一个AuthInterceptor，在请求进入Controller之前判断Session里有没有用户信息，没有就重定向到登录页。再根据请求URL和角色做二次判断。

我这里给你一个简化版的拦截器逻辑：

public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User user = (User) session.getAttribute("loginUser"); if (user == null) { response.sendRedirect("/login"); return false; } // 按路径前缀限制角色 String uri = request.getRequestURI(); if (uri.startsWith("/admin") && !"ADMIN".equals(user.getRole())) { response.sendError(403); return false; } if (uri.startsWith("/teacher") && !"TEACHER".equals(user.getRole())) { response.sendError(403); return false; } return true; } }

然后在WebConfig里注册拦截器，设置放行的路径，比如/login、/static资源等。

这里有个容易被忽略的细节：如果你用了Thymeleaf，前端页面里用th:if="${session.loginUser != null}"来显示不同菜单。但拦截器才是真正的安全边界，前端隐藏菜单只是体验优化，不是安全方案。

4.2 班级和排课的实现

班级管理模块看起来就是个普通的CRUD，但排课冲突检测是最能体现你业务能力的地方。

新增班级时，前端表单要提交：班级名称、课程、教师、开课日期、结课日期、每周上课日和起止时间、容量。Service层在插入班级前，先做一个查询：

List<Classes> conflictList = classesMapper.selectByTeacherAndTime( teacherId, weekDay, startTime, endTime); if (conflictList != null && !conflictList.isEmpty()) { throw new RuntimeException("该教师此时间段已有排课，请重新选择时间"); }

对应的SQL大概是这样：

<select id="selectByTeacherAndTime" resultType="..."> SELECT * FROM classes WHERE teacher_id = #{teacherId} AND week_day = #{weekDay} AND status = 0 AND (start_time &lt; #{endTime} AND end_time &gt; #{startTime}) </select>

核心判断就是两个区间是否重叠：只要原班级的start_time小于新班级的endTime，并且原班级的end_time大于新班级的startTime，就说明重叠了。这个不等式你最好理解清楚，因为答辩极可能被问到。用生活化方式解释就是：两条排队队伍，只要A队的尾没在你B队头之前，A队的头也没在你B队尾之后，就说明两队有时间交叉。

4.3 报名缴费退款的完整流程

报名缴费是整个系统业务逻辑最重的部分。请求一旦发起，后台需要同时干几件事：

1. 检查班级状态是否为招募中。
2. 检查班级当前enrolled是否小于capacity。
3. 创建enrollment记录，状态设为已报名。
4. 增加classes的enrolled字段。
5. 创建payment记录，金额记入财务流水。

这五步必须保证要么全部成功，要么全部失败。最稳妥的方式是先用@Transactional把整个方法包起来，然后写一个报名事务服务方法。我建议不要在一个Controller里写这些逻辑，而是放到EnrollmentService里。

以缴费记录为例，Service方法签名可以这样设计：

@Transactional public void enroll(EnrollmentDTO dto) { Classes classes = classesMapper.selectByIdForUpdate(dto.getClassId()); if (classes == null || !"OPEN".equals(classes.getStatus())) { throw new ServiceException("班级不存在或未开放报名"); } if (classes.getEnrolled() >= classes.getCapacity()) { throw new ServiceException("班级名额已满"); } Enrollment enrollment = new Enrollment(); enrollment.setStudentId(dto.getStudentId()); enrollment.setClassId(dto.getClassId()); enrollment.setStatus("ACTIVE"); enrollmentMapper.insert(enrollment); classes.setEnrolled(classes.getEnrolled() + 1); classesMapper.updateEnrolled(classes.getId(), classes.getEnrolled()); PaymentRecord payment = new PaymentRecord(); payment.setEnrollmentId(enrollment.getId()); payment.setAmount(classes.getCourse().getPrice()); payment.setPayTime(new Date()); payment.setPayType(dto.getPayType()); paymentMapper.insert(payment); }

看到selectByIdForUpdate了吗？这是数据库行锁，先说结论：如果你不需要处理并发，普通select也行；但如果你想展示一点亮点，就用for update锁住班级行，防止并发下超卖。这个点后面我会单独讲。

退款逻辑刚好是反着来的：修改enrollment状态为refund，班级enrolled减1，同时生成一条退款记录。注意退款金额要和原缴费单关联，不能随手填，否则财务账会对不上。

4.4 用SQL直接搞定统计

报表是培训班管理系统的加分项。不要在Java里循环算数据，直接在SQL里用聚合函数，简单又高效。我整理了几个必做的统计：

统计每个班级的学员人数：

SELECT c.id, c.class_name, COUNT(e.student_id) AS student_count FROM classes c LEFT JOIN enrollment e ON e.class_id = c.id AND e.status = 'ACTIVE' GROUP BY c.id, c.class_name;

月度营收统计：

SELECT DATE_FORMAT(pay_time, '%Y-%m') AS month, SUM(amount) AS total_amount FROM payment GROUP BY month ORDER BY month DESC;

教师课时量统计可以通过考勤表关联classes实现：

SELECT t.name AS teacher_name, COUNT(a.id) AS total_hours FROM attendance a JOIN classes c ON a.class_id = c.id JOIN teacher t ON c.teacher_id = t.id WHERE a.status = 'PRESENT' GROUP BY t.id;

做了这几个统计后，前端用ECharts或Chart.js画一个简单的柱状图/折线图，答辩的时候视觉效果非常好。你完全可以直接说“系统可以支撑机构查看月度营收变化”这样的功能，老师一听就知道你的系统不只是demo。

5. 并发、事务和联表查询：这块写好了答辩很加分

5.1 为什么报名扣名额必须用事务

我刚才强调过，报名时那几步必须同一个事务。这里我再详细解释一下为什么。假设报名流程不是事务：第一步插入enrollment成功了，第二步更新班级人数失败了，那么就会出现一条报名记录但班级人数没增加的情况，接下来第十一个人也能报名一个只有10个名额的班，这就是数据不一致。

事务的存在就是为了解决这种“多个操作要么同时成功，要么同时失败”的问题。Spring里用@Transactional注解就行，但要注意它默认只在RuntimeException（运行时异常）下回滚，如果你catch了异常又没抛出去，事务就失效了。我遇到过有同学在这里踩坑：Service方法里try catch吞掉异常，结果数据库出现脏数据。事务方法里别随便catch，如果需要捕获，要手动TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。

5.2 乐观锁解决最后名额的竞争

如果不做并发控制，两个学员同时抢最后一个班级名额，可能出现两个人都查到enrolled=9、capacity=10，然后都插入成功，班级变成11个人。这在实际机构里就是超卖，在毕设答辩里就是十足的高危漏洞。

最简单有效的方案是给classes表加一个version字段（int），更新时带上version条件：

UPDATE classes SET enrolled = enrolled + 1, version = version + 1 WHERE id = #{id} AND version = #{oldVersion}

如果返回的影响行数为0，说明这条班级记录在更新前已经被其他人改过了，要报“名额已满”或让用户重新查询。这个方案叫乐观锁，比行锁更易理解，也更好向老师解释。用生活化类比：就像两个人同时改一份文档，谁先保存成功谁生效，后保存的人发现版本号对不上，只能重新操作。

当然，前面提到的selectByIdForUpdate是悲观锁方案，它更直接，但实现时要注意锁的粒度，尽量锁行而不是锁表。答辩时你可以说“我在报名场景用了悲观锁，后面发现可能带来锁等待，所以又用乐观锁做了兜底”，这样层次感就出来了。

5.3 MyBatis中的动态SQL和联表查询

培训班管理系统的列表页往往都有筛选条件：按姓名模糊搜索、按班级筛选、按报名时间范围筛选、按状态筛选。如果每个条件写一个SQL，代码要爆炸。用MyBatis动态SQL就能一个查询搞定：

<select id="searchEnrollments" resultType="..."> SELECT e.id, s.name AS student_name, c.class_name AS class_name, e.enroll_time, e.status, p.amount AS pay_amount FROM enrollment e LEFT JOIN student s ON e.student_id = s.id LEFT JOIN classes c ON e.class_id = c.id LEFT JOIN payment p ON p.enrollment_id = e.id <where> <if test="studentName != null and studentName != ''"> AND s.name LIKE CONCAT('%', #{studentName}, '%') </if> <if test="classId != null"> AND e.class_id = #{classId} </if> <if test="status != null and status != ''"> AND e.status = #{status} </if> </where> ORDER BY e.enroll_time DESC </select>

这里用了LEFT JOIN而不是INNER JOIN，是为了让没有缴费记录的报名记录也能显示出来，方便管理员看到状态。同时多表关联时字段名一定要加表前缀，不然多张表都有id就会出现“id is ambiguous”的报错。

这个动态SQL的用法，建议你在答辩前彻彻底底弄明白。因为这是MyBatis最重要也最常用的能力，老师一眼就能看出来你是不是真的用过这个框架。

6. 页面与接口联调：前端不要写得像“文档管理器”

6.1 统一返回体与异常处理

毕设系统经常前后端用Thymeleaf混在一起，但不管是服务端渲染还是接口返回JSON，统一数据格式都是必要的。我建议定义一个Result类，所有Controller接口都返回这个结构：

public class Result<T> { private Integer code; // 200成功，400业务错误，500系统错误 private String message; private T data; }

同时配一个@RestControllerAdvice的全局异常处理器，把ServiceException和校验异常统一转成Result返回。这样前端接收数据时只需要判断code，不用每个页面分别处理异常。

如果你用的是非前后端分离模式，也可以让Controller直接返回视图名，但遇到Ajax请求时返回JSON。也就是说，普通页面跳转走服务端渲染，交互操作（比如删除、审核、报名）走Ajax异步请求。这种混合模式是毕设最舒服的组合：既有SEO，又不用整页刷新。

6.2 列表页、表单页、弹窗操作的标准套路

我建议所有列表页都统一成一个套路：顶部是搜索表单，中间是表格，右侧是操作列，点击新增或编辑弹出模态框。模态框里放一个form表单，提交时用Ajax发送到后台。

分页功能别自己手写太多，只要用PageHelper插件就行。引入依赖后，在Mapper查询前写：

PageHelper.startPage(pageNum, pageSize); List<EnrollmentVO> list = enrollmentMapper.searchEnrollments(condition); PageInfo<EnrollmentVO> pageInfo = new PageInfo<>(list);

PageInfo里已经有总条数、页数、当前页数据，直接传给前端即可。前端Thymeleaf模板可以用th:each渲染表格行，也可以用JavaScript监听分页按钮。这种写法简单稳定，不容易出bug。

6.3 前后端双重校验

前端校验是为了用户体验，后端校验才是安全底线。比如“手机号”字段，前端用HTML的required和pattern属性，可以提示“请填写正确的手机号”。但如果有人绕过前端直接调接口，比如用Postman发请求，后端不校验就会写入脏数据。所以后端在Service层也要做校验。

我一般会写一个简单的校验工具类，使用Spring自带的Validator或者直接手写正则：

public static boolean isValidPhone(String phone) { if (phone == null) return false; return phone.matches("^1[3-9]\\d{9}$"); }

注意，这里手机号的校验只是示例，不同国家的号码规则不一样，你按自己国家业务来就行。后端校验不通过，就直接抛ServiceException，全局异常处理器统一返回提示信息。

7. 部署前的自测与常见故障排查

7.1 启动失败的通用排查

到了临近提交的时候，最怕的就是系统起不来。我总结了一个从现象到原因的排查思路，按顺序走基本能解决大部分问题：

1. 项目启动报Port 8080 was already in use：说明端口被占用。要么关掉占用程序，要么改端口。
2. 报Access denied for user 'root'@'localhost'：说明MySQL用户名密码不对，去application.yml里核对。
3. 报Unknown database：说明数据库没建，或者url里库名写错。
4. 报ClassNotFoundException或NoClassDefFoundError：一般是Maven依赖没下全，先执行mvn clean package，不行就删掉本地仓库里对应的依赖重新下载。
5. 报数据库时区错误：检查连接串是否带serverTimezone=Asia/Shanghai。

7.2 本地跑通与打包部署

毕设通常在这个环节只需要提交源码和演示视频，不需要真正部署到云服务器。但为了让演示更流畅，我建议你在本地把项目打成JAR包再启动，避免开发环境和打包环境不一致。

Java项目打包命令：

mvn clean package -DskipTests

打出来的JAR一般在target目录下，然后运行：

java -jar target/training-system-0.0.1-SNAPSHOT.jar

如果JAR包里包含了前端静态资源（Thymeleaf模板和JS/CSS），这个JAR就是一个完整的可运行服务。浏览器访问http://localhost:8080就能看到系统。

7.3 演示数据怎么造

很多同学只做功能，演示时表格里空荡荡的，老师看了毫无感觉。建议提前准备一批逼真的演示数据：比如学员30人、教师5人、班级8个、每个班配若干缴费记录和考勤记录。重点是让统计报表有数据可看。

造数据的方式可以直接写一个DataInitializer类，在项目启动时自动插入演示数据，前提是判断表为空才插入。也可以在数据库里手写SQL插入，但那样的话换台电脑重跑项目又要重新导数据。我个人推荐做成自动初始化，这样答辩现场换电脑也能直接跑起来。

8. 答辩时那些老师一定问的问题

8.1 你的系统创新点在哪里

培训班管理系统是个老题目，老师不会奢望你做出“革命性创新”，但你可以从工程角度提炼亮点。我当时总结的三个点：

• 排课冲突检测：通过时间区间重叠判断，防止教师课程冲突。
• 报名超卖防护：使用乐观锁/悲观锁保证班级人数准确。
• 数据可追溯：所有核心数据使用软删除和状态字段，保留完整操作记录。

这三个点都是从真实业务问题出发，没有一个是为了写代码而写代码。老师问到就说清楚“为什么需要”“怎么实现”“还有没有优化空间”，绝对加分。

8.2 数据库表设计为什么这样

老师喜欢问“你的班级和学员为什么用中间表”“缴费记录为什么不直接挂在学员表下”。你要能解释：班级和学员是多对多关系，所以用enrollment作为关联表；缴费记录与报名记录是一对多关系，缴费单必须挂在报名记录下，才能关联到具体的班级和课程。同时，把价格复制到payment表而不是实时查课程表，是为了保留缴费那一刻的历史快照，防止以后课程涨价导致历史账单变动。这个细节很能体现你对财务业务的理解。

8.3 如何证明你的系统“真正完成了”

最好的证明方式不是背代码，而是现场演示几个关键操作：新增一个班级、用不同角色登录看权限差异、报名一个名额还剩1个的班级并验证超卖防护、查看月度统计报表。你在演示过程中把Service层的校验逻辑和SQL查询讲清楚，比嘴上说“已经做完了”有说服力得多。

如果在答辩前还有时间，记得把项目README写一下，包含启动步骤、默认账号密码、核心表说明。到时候老师拿着你的文档操作一遍，体验会好很多。

这些经验都是我在做类似系统时一步步趟出来的。实话实说，培训班管理系统这个题不难，难点在于你能不能把每个环节想透，而不是只把代码抄一遍。顺着需求分析、数据库、核心业务、并发控制、测试部署这套链路走下来，你会发现它一点都不空洞，反而是一个能让你把大学四年Java知识串起来的完整项目。