驾校预约管理系统我在接手过的毕业设计项目里见过太多版本了。有学生拿Spring Boot快速搭一个界面套个模板跑通就算完事也有同学老老实实用SSMSpring SpringMVC MyBatis手写整合结果卡在配置上两三天出不来。但说句实话真正到了答辩现场或者面试的时候能用SSM把这个系统讲清楚、讲透反而比直接甩一个Spring Boot成品更有说服力因为SSM逼迫你理解每一层到底在干什么。这篇文章我就围绕“基于SSM的驾校培训预约管理系统”这个经典选题把从需求拆解、数据库设计、权限控制、预约核心流程到部署排错的全过程拆开讲。如果你正在做这个题目或者想拿一个Java Web练手项目巩固SSM框架这篇文章能帮你少走很多弯路。我会把重点放在“预约冲突怎么处理”和“SSM整合的坑”这两个最容易让项目翻车的点并补上真实项目中才会用到的设计与优化思路。1. 为什么驾校预约系统更适合用SSM而不是无脑上Spring Boot很多同学拿到这个题目第一反应是“SSM已经过时了直接用Spring Boot不香吗”。我先给一个结论作为学习项目SSM能让你把Web开发的地基打牢固作为毕设去答辩SSM反而更好讲。1.1 SSM框架各自在系统中扮演什么角色SSM是三个框架的组合体分工非常清楚Spring负责管理业务对象也就是Service层的Bean以及事务控制。在驾校预约系统里“创建预约记录”和“扣减教练的可用时段”必须在一个事务里完成这靠的就是Spring的声明式事务。SpringMVC负责接收前端发来的HTTP请求把请求参数绑定到Java对象再去调用Service层最后把返回结果渲染到JSP页面或返回JSON数据。MyBatis负责数据库访问把Java对象映射成SQL参数再把查询结果集映射回Java对象。在预约系统里查询教练空闲时间、插入预约记录、更新练车状态全部走MyBatis的Mapper接口。这个架构的好处是“层与层之间的边界极其明确”。Controller只处理请求分发Service只写业务逻辑Mapper只写SQL。答辩时老师问“你这条预约记录的创建流程是什么”你可以非常清晰地说出请求走过了哪几层每一层做了什么。1.2 这套系统的核心业务难点在哪驾校预约管理系统表面上看是个常规的CRUD系统但它有一个非常典型的核心难题预约冲突检测。场景是这样一个教练一天有多个时间段比如上午8点到10点一个时段10点到12点一个时段每个时段只能分配给一个学员。两个学员同时提交了同一个教练、同一个时段的预约请求系统只能允许一个人预约成功。这个问题没有处理好就会出现“明明约了车到驾校发现另一个学员也在车上”的尴尬情况。如果只用Spring Boot很多AI生成的代码只会写一个简单的insert根本不处理并发冲突而用SSM时你会被迫去思考在数据库层面怎么防冲突在业务层面怎么提示学员。这个思考过程才是答辩时真正有价值的亮点。1.3 技术选型需要考虑的现实因素从项目开发环境来说SSM项目几乎都是传统的Maven工程配合Tomcat运行依赖管理清晰调试也直接。当然如果你做的系统需要频繁的前后端分离部署、高并发抢课、小程序端接入那我肯定建议用Spring Boot MyBatis-Plus Redis那是另一个维度的事。但对于驾校预约这种内部管理系统用户量就是几百个学员加几十个教练SSM这套体系在性能、稳定性上绰绰有余而且更贴合大多数高校的课程设计大纲。提示如果导师没有强制要求技术栈而你又想在答辩时把系统说得更有底气和深度SSM是一个比Spring Boot更优的选择——因为你能把每一个配置都解释清楚。2. 数据库设计预约系统的地基是“状态”与“时间片”我见过太多驾校预约项目把数据表设计得极其随意——一张学员表、一张教练表、一张预约表就完事。这种设计在演示的时候看着没问题一旦演示到“取消预约”“教练确认”“学员评价”这类流程就发现表结构根本支撑不住。2.1 核心表结构与设计思路一套能支撑完整业务流程的表至少要包含这几张表名作用关键字段user统一用户表存放三类账号id, username, password, role, real_name, phonecoach教练扩展信息id, user_id, car_model, years, score, statusstudent学员扩展信息id, user_id, id_card, exam_status, total_hourscourse_schedule教练的授课时段表id, coach_id, date, start_time, end_time, is_bookedappointment预约业务主表id, student_id, schedule_id, status, create_time, remark为什么要单独设计一张course_schedule表而不是让教练每天手动在系统里无限制被预约因为驾校是有固定训练时段的。以我接触过的实际驾校为例练车时间一般分为上午、下午、傍晚三个大段每个大段下再拆成若干个2小时小段。教练和车辆是绑定关系每个时段只能容纳一个学员训练。所以在设计时预约的对象不是一个抽象的“教练”而是教练在某个具体日期、具体时间段内的一个可预约片段。谁先提交预约谁获得这个片段其他人只能看到“该时段已被预约”。2.2 状态字段是业务流程的开关预约表里的status字段是整个系统的灵魂我建议设计成如下状态机0待确认学员提交预约等待教练/管理员审核1已确认教练确认排班学员可以按时到校2已完成练车结束双方都可以评价3已取消学员或教练取消了该预约4已爽约学员未按时到校标记违约状态流转的规则要写死在Service层里不允许从任意状态跳到任意状态。比如待确认和已确认状态的记录不能直接变成已完成必须经过真实的练车时间。这道规则只要写得清楚答辩时老师一问“如果学员预约了但没来怎么办”你就能立刻给出完整的状态处理逻辑。2.3 时间字段的数据类型建议时间字段推荐用datetime或者time类型不要存字符串。预约查询里有一个高频SQL是按日期查教练排班SELECT * FROM course_schedule WHERE coach_id #{coachId} AND date #{date} AND is_booked 0 ORDER BY start_time ASC;如果date存的是字符串比较时会走隐式转换索引直接失效。我的习惯是日期字段统一用DATE类型时间段用TIME类型业务时间戳比如create_time用TIMESTAMP类型。这个细节在数据库设计评审时是个加分项。3. 权限与角色三种身份在一个系统里的闭环驾校预约系统里至少有三类角色管理员、教练、学员。如果不做权限控制任何登录用户都能访问所有页面那这个系统就是个玩具。3.1 用户身份的统一与区分我强烈建议不要为每个角色单独建表而是把登录账号统一放在一张user表里用role字段区分身份再用coach和student表存放各自的扩展信息。这样好处很直接登录逻辑只要写一份权限控制只认role字段后续要加“系统管理员”还是“财务”只要扩展role枚举值不用改表结构角色与账户的实际关联示例public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { User user (User) request.getSession().getAttribute(loginUser); if (user null) { response.sendRedirect(request.getContextPath() /login); return false; } // 管理员可访问 /admin/**教练可访问 /coach/**学员可访问 /student/** String uri request.getRequestURI(); if (uri.contains(/admin/) !ADMIN.equals(user.getRole())) { response.sendError(403); return false; } return true; } }这段代码就是SpringMVC拦截器的典型用法。很多同学在写权限控制时会把它写在每个Controller方法里比如每个方法开头都判断一次if (session.getAttribute(role).equals(admin))——这样倒也能运行但代码冗余严重也不利于后续维护。用拦截器统一去做是这个系统里的最佳实践。3.2 三套业务闭环怎么设计系统的业务闭环其实可以拆成三条线学员端流程注册登录 → 查看教练列表 → 查看教练的可用时段 → 提交预约 → 等待确认 → 查看自己的预约记录 → 完成练车后评价教练。教练端流程登录查看今日待确认预约 → 确认/拒绝预约 → 查看未来日程 → 标记学员练车完成 → 给学员打分写评语。管理端流程管理教练和车辆信息 → 审核学员注册 → 查看所有预约记录 → 处理爽约记录 → 统计各教练被预约率 → 管理公告。三条线共用的是appointment表但查询视角完全不同学员端按student_id查教练端按schedule_id关联教练查管理员端则可以查全表。这种“一张主表多方使用”的设计非常考验对业务理解是否到位。3.3 密码存储与安全的低成本做法毕设项目里很多人喜欢明文存密码这在答辩时是一个硬伤。其实安全手段不用做得多高级只需要两步就能说得过去注册时用MD5或者BCrypt对密码做哈希数据库中只存哈希值登录时只比对哈希值以MD5为例虽然它现在已经不算安全但在教学项目中展示思路是够的。更推荐的做法是JDK自带的MessageDigest配合一个固定的盐再哈希一遍public static String md5WithSalt(String password) { String salted password driving_school_salt; try { MessageDigest md MessageDigest.getInstance(MD5); byte[] bytes md.digest(salted.getBytes(StandardCharsets.UTF_8)); StringBuilder sb new StringBuilder(); for (byte b : bytes) { sb.append(String.format(%02x, b)); } return sb.toString(); } catch (NoSuchAlgorithmException e) { throw new RuntimeException(e); } }这个细节虽然简单但能向老师证明你具备基本的安全意识——这不是一个只会写增删改查的学生。4. 预约核心流程事务、锁与并发冲突的实战处理这章是整个系统的技术高地也是最值得在答辩时展开讲的部分。驾校预约和“抢课”“抢票”本质上是一类问题稀缺资源 并发请求 数据一致性。4.1 冲突检测的第一道防线数据库字段约束最简单的防冲突方案是在course_schedule表里加一个is_booked字段0表示空闲1表示已占用。学员预约时先执行一次查询判断SELECT * FROM course_schedule WHERE id #{scheduleId} AND is_booked 0;如果查到了空闲记录就执行预约插入。但这里有一个隐患两个学员同时执行这一次查询都查到了is_booked0然后都执行插入最终就出现了同一时段被两个人预约的情况。4.2 如何用事务 行锁解决并发覆盖解决思路其实很经典不要用两段独立的SQL去完成“查询再更新”而是用一条带条件的UPDATE语句直接完成原子化占用。update idoccupySchedule UPDATE course_schedule SET is_booked 1, student_id #{studentId}, version version 1 WHERE id #{scheduleId} AND is_booked 0 /update这条SQL执行的返回值为int在MyBatis中如果影响行数为1说明更新成功如果为0说明时段已被别人抢先预约。判断完返回值再做插入预约记录的操作再提交事务。但仅仅这样还不够严谨。设想一下UPDATE执行成功了但在插入预约记录之前事务还没有提交此时另一个请求尝试预约——按InnoDB默认的REPEATABLE READ隔离级别它会被行锁挡住等第一个事务提交后才继续执行。所以关键点是这条UPDATE语句要在一个事务里并且后续的预约记录插入也在同一个事务里。Service层的标准写法大概是Transactional(rollbackFor Exception.class) public Appointment createAppointment(AppointmentVO vo) { // 1. 原子化占用时段 int occupied courseScheduleMapper.occupySchedule(vo.getScheduleId(), vo.getStudentId()); if (occupied 0) { throw new BusinessException(该时段刚被其他学员预约请选择其他时间); } // 2. 插入预约记录状态为待确认 Appointment appointment new Appointment(); appointment.setScheduleId(vo.getScheduleId()); appointment.setStudentId(vo.getStudentId()); appointment.setStatus(0); appointmentMapper.insert(appointment); return appointment; }这里Transactional保证了要么occupySchedule和insert同时成功要么同时回滚。如果把事务配置交给Spring管理rollbackFor Exception.class一定要写因为Spring默认只在遇到RuntimeException时回滚如果自定义了一个BusinessException继承了Exception但不配置rollbackFor事务是不会回滚的。这个细节踩过坑的人最有体会。4.3 乐观锁版本号方案还是悲观锁方案我这里用的是“条件更新即乐观锁”的思路不额外依赖version字段也行只要WHERE条件里带is_booked 0就相当于把版本判断和更新合并成了一步原子操作。如果你希望更严谨可以在course_schedule表里增加一个version整数列每次更新时把version作为条件之一更新成功再把version 1。在冲突极少、并发量不高的驾校预约场景下不引入额外字段是更简洁的选择。关于是否用SELECT ... FOR UPDATE这种以后的方式我的建议是可以被问到但不要真的在项目里用它。因为行锁的持有时间会拉长一旦写业务代码时没注意很容易把事务锁持有到不该持有的时刻排查起来很痛苦。像驾校预约这种低并发场景条件更新已经足够。4.4 状态流转的业务校验除了并发冲突预约状态之间的流转也要做校验。比如只有待确认状态的预约可以被学员取消只有已确认状态的预约在练车结束后可以被标记为已完成。这块最简单的实现方式是在Service里写switch或者if判断。我在实际项目里更习惯建一个AppointmentStatusMachine类集中管理可以流转的状态路径public class AppointmentStatusMachine { private static final MapInteger, SetInteger TRANSITIONS new HashMap(); static { // 0待确认 - 1已确认 / 3已取消 TRANSITIONS.put(0, new HashSet(Arrays.asList(1, 3))); // 1已确认 - 2已完成 / 4已爽约 / 3已取消提前取消 TRANSITIONS.put(1, new HashSet(Arrays.asList(2, 3, 4))); } public static boolean canTransit(int from, int to) { SetInteger allowed TRANSITIONS.get(from); return allowed ! null allowed.contains(to); } }状态机的好处是当系统越来越复杂的时候新增一个状态不太会破坏原有的流转逻辑。在答辩的时候把这个类拿出来讲说明你思考过业务状态的彻底建模这比“我用一个int字段存状态”要高级一个层次。5. SSM整合实战搭建骨架过程中最容易卡住的几个地方SSM项目的开发体验和Spring Boot完全不同。Spring Boot把99%的配置都自动完成了而SSM要求你手动把Spring容器、SpringMVC容器、MyBatis的SqlSessionFactory全部拼装起来。只要一个配置出错项目就起不来报错信息还不那么直观。5.1 Maven依赖版本怎么选才不出错依赖版本是SSM整合的第一道大坑。我整理了一套经常在项目里稳定运行的版本组合直接参考这一组组件版本JDK1.8Maven3.6.3Spring5.3.30MyBatis3.5.13mybatis-spring2.0.7MySQL Connector/J8.0.33Druid 连接池1.2.15Servlet API4.0.1Jackson2.13.4一条非常实际的建议MyBatis和mybatis-spring的版本要匹配。mybatis-spring 2.0.x对应MyBatis 3.5.x如果你用了MyBatis 3.4.x再配mybatis-spring 2.0.x启动时可能会报绑定异常。5.2 Spring和SpringMVC的容器关系SSM里最容易混淆的是Spring和SpringMVC两个容器的关系。很多同学的配置文件里把Controller的扫描放进了Spring的扫描范围导致Service和Controller重复创建事务切面失效或者访问页面时出现令人困惑的404。正确做法是这样的applicationContext.xml父容器只扫描com.driving.service和com.driving.dao等业务层和持久层组件spring-mvc.xml子容器只扫描com.driving.controller同时配置注解驱动和视图解析器!-- applicationContext.xml 中关键配置 -- context:component-scan base-packagecom.driving context:exclude-filter typeannotation expressionorg.springframework.stereotype.Controller/ /context:component-scan !-- spring-mvc.xml 中关键配置 -- context:component-scan base-packagecom.driving.controller/ mvc:annotation-driven/如果不做这个排除配置极端情况下会出现“一个Controller走了多个代理对象”的诡异问题排查起来特别耗时。5.3 MyBatis Mapper扫描的两种方式MyBatis和Spring整合后Mapper接口的扫描方式推荐用MapperScan注解写在Spring的配置类上或者直接在applicationContext.xml里声明bean classorg.mybatis.spring.mapper.MapperScannerConfigurer property namebasePackage valuecom.driving.dao/ /bean同时MyBatis的mapper-locations要指向XML映射文件property namemapperLocations valueclasspath:mapper/*.xml/一个小提醒如果XML映射文件和Mapper接口不在resources目录同一个包路径下运行时经常会报“Invalid bound statement (not found)”。这个错误十有八九是mapper-locations路径没配对。另外要留意Maven工程里src/main/java下的XML文件默认不会打到classes目录如果想把Mapper XML和接口放在一起需要在pom.xml的build里显式配置resources。5.4 前端页面和后端请求的连接方式SSM时代的项目一般用JSP做服务端渲染Controller返回一个视图名称配合InternalResourceViewResolver解析成JSP路径。如果你对前端工程化不熟用JSP是靠谱的Thymeleaf虽然更现代但对SSM的整合成本更高。如果你希望局部刷新比如预约时段列表切换时不用整个页面刷新那就让Controller返回JSONResponseBody RequestMapping(/coach/schedule) public Result getSchedules(RequestParam Integer coachId, RequestParam String date) { ListCourseSchedule list scheduleService.getAvailableSchedules(coachId, date); return Result.success(list); }这里配合Jackson依赖Spring会自动把返回对象序列化成JSON。注意Result要设计成统一返回体里面放code、message和data三个字段前端只需判断code是否为200。6. 高频踩坑实录从配置错误到数据诡异的排查链路SSM开发过程中踩坑是常态我挑几个典型问题把排查思路完整写出来方便你遇到的时候能一步步定位而不是乱试一气。6.1 “Invalid bound statement (not found)”怎么查这个报错是Mapper接口和XML映射文件没有正确绑定。我在一个实际项目里排查过类似的错误最终定位到是resources目录下的mapper目录打jar包时被排除了。排查链路可以这样走先打开项目编译后的target/classes目录确认mapper/CoachMapper.xml是否存在如果不存在在pom.xml里补上resources配置让XML文件打进classes如果存在检查applicationContext.xml里的mapperLocations路径和实际目录是否严格一致再检查Mapper接口的namespace是否等于接口的全限定名比如com.driving.dao.CoachMapper最后确认SQL语句中id方法名和接口中的方法名是否一致、参数类型是否匹配多数情况走到前三步就能解决问题。6.2 页面全是乱码/中文变成问号这个问题通常有三个层面请求编码、响应编码、数据库编码。请求编码在web.xml里配置CharacterEncodingFilter强制设置UTF-8响应编码如果返回的是JSON在SpringMVC的注解驱动里配置消息转换器如果是JSP在JSP页面头部加pageEncodingUTF-8数据库编码创建数据库时指定CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci连接URL里加characterEncodingutf8MySQL 8.0连接字符串建议写完整jdbc:mysql://localhost:3306/driving_school?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8漏掉serverTimezone在连接时会直接报时区错误这个已经是老生常谈但每届都有人中招。6.3 事务不生效update成功但异常后没有回滚典型现象预约流程中占用时段成功但插入预约记录时因为某个约束抛了异常结果前台报错了后台数据里时段却真的被占了。优先级最高的排查点就是Transactional没有正确配置确认spring-tx依赖存在确认tx:annotation-driven transaction-managertransactionManager/已配置确认Service实现类被Spring扫描到且方法必须是public确认异常类型在事务回滚范围内。默认只会回滚RuntimeException所以最稳妥的做法是在Transactional里显式声明rollbackFor Exception.class还有一个很容易被忽视的点Spring的事务是通过AOP代理实现的同类内部方法调用不走代理。比如在AppointmentService里有一个public createAppointment()调用了同类里的private doInsert()doInsert()上的事务注解是不生效的因为调用发生在对象内部没有经过代理。这就要求把事务边界放在对外暴露的方法上事务内部的逻辑尽量拆成私有方法。6.4 上传图片后刷新才能看到新图片这个不是SSM特有的坑但是做驾校项目时很容易遇到——教练头像或学员驾驶证上传后浏览器还在用缓存的旧图片。解决思路一般有两种在静态资源路径里加版本参数也就是图片URL后面拼一个时间戳或者后端返回文件下载接口每次通过ControllerResponseBody返回字节流并设置响应头Cache-Control: no-cache驾校系统里对实时性要求最高的其实是学员练车照片或打卡记录如果图片更新不生效就要往缓存控制这个方向查。6.5 部署到Tomcat后出现404URL前缀问题本地用IDEA直接运行没问题打war包丢到Tomcat的webapps后访问默认应用路径时404了。这个问题的本质是应用上下文路径变了。原则上所有内部跳转都不要写死根路径一律用相对路径或${pageContext.request.contextPath}也就是以应用的上下文路径为前缀。我在实际项目里习惯在JSP页面统一引入% taglib prefixc urihttp://java.sun.com/jsp/jstl/core % c:set varctx value${pageContext.request.contextPath} /然后在所有请求、跳转、静态资源引用时统一加${ctx}前缀。这是SSM项目中最基础也最常见的一个规范。7. 把项目从“能跑”升级到“能讲”答辩加分的设计思路最后一个部分谈谈怎么在现有基础上做增量设计让系统不只是演示一遍CRUD就结束。7.1 增加一个Redis缓存层驾校系统的数据量不大但“查教练可预约时段”是一个高频查询。可以用Redis做一层缓存在更新排班、预约成功后主动失效缓存。这个设计不需要把整个项目重写只需要在Service层做一个小改造public ListCourseSchedule getAvailableSchedules(int coachId, String date) { String key schedule: coachId : date; String cached redisTemplate.opsForValue().get(key); if (cached ! null) { return JSON.parseArray(cached, CourseSchedule.class); } ListCourseSchedule list courseScheduleMapper.selectAvailable(coachId, date); redisTemplate.opsForValue().set(key, JSON.toJSONString(list), 10, TimeUnit.MINUTES); return list; }预约成功后要记得删除对应key避免旧数据回显redisTemplate.delete(schedule: coachId : date);这段逻辑放在Service里非常自然。答辩时如果老师问“如果并发量再大一点你怎么办”这就是现成的进阶答案。7.2 增加练车进度跟踪模块驾校培训有一个天然的业务规则学员需要修满足够学时才能约考。可以用一个study_record表记录每次练车的开始时间和结束时间累计出总学时学员端就能看到自己的进度条管理员端可以统计每个学员是否达到约考门槛。设计表时可以简单理解为字段含义record_id记录IDstudent_id学员IDappointment_id关联的预约IDstart_time实际练车开始时间end_time实际练车结束时间duration_minutes本次练车有效分钟数这个模块能扩展的内容很多如何防止学员刷时长、教练和学员双方确认结束才能计入学时、超时未开始如何自动取消预约——每一个细节都是可以深入展开的答辩点。7.3 用ECharts做一个教练档期利用率统计管理员端加一个统计图表非常能提升项目的观感。用ECharts展示“一周内各教练的时段占用率”其实很简单后端写一个接口查询预约记录按日期和教练分组统计已占用时段数量前端用柱状图或饼图渲染。统计SQL是典型的分组查询SELECT cs.coach_id, cs.date, COUNT(*) AS total_slots, SUM(CASE WHEN cs.is_booked 1 THEN 1 ELSE 0 END) AS booked_slots FROM course_schedule cs WHERE cs.date BETWEEN #{startDate} AND #{endDate} GROUP BY cs.coach_id, cs.date这个模块不需要复杂的算法但能直观地展示数据可视化能力在项目演示时是很亮眼的一环。7.4 开发过程中要注意代码规范与注释这个听起来像是废话但实际改代码时非常有用。我给自己定过规矩所有Service层方法必须写Javadoc注释说明参数含义、返回值含义、异常场景。Mapper XML里的SQL必须和字段名对齐不允许出现SELECT *。项目代码的结构一般建议这样组织src/main/java ├── com.driving │ ├── controller // 控制层 │ ├── service // 业务接口 │ │ └── impl // 业务实现 │ ├── dao // MyBatis Mapper接口 │ ├── entity // 实体类 │ ├── vo // 前端交互视图对象 │ ├── common // 通用工具、统一返回体、异常类 │ └── config // 拦截器、Redis、事务配置我在实际开发中还喜欢把common包里放一个BusinessException全局异常处理器配合ControllerAdvice统一处理系统异常这样Controller层就不会到处是try-catch了。8. 写在最后关于这个系统的几点真实体会这套驾校预约管理系统从难度上说不是最难的但它的业务场景非常贴近真实世界比“图书管理系统”和“学生管理系统”这种纯CRUD选题好讲得多因为驾校预约天然包含了资源冲突、时间约束、状态流转和角色权限这些真实系统里一定会遇到的命题。我在带项目过程中最大的体会是不要急着写代码先用一天时间把数据库表结构和状态流转图画出来。表结构定了状态流转顺了后面写代码就是搬运工的工作反过来如果表设计是临时想的写着写着就会陷入“这个状态该放哪里”的死循环。另一个建议是多去真实驾校的业务流程里找灵感。比如约考接口的对接逻辑、不同车型的定价、教练上下午时段的可配置化、节假日的排班规则这些都是可以填充进系统里的业务细节。把任何一个点做透都比把十个点都一笔带过更有竞争力。最后再分享一个小技巧开发和答辩前一定用真实的多角色账号完整走一遍核心流程。很多学生答辩翻车不是因为功能没写出来而是因为在演示的时候用学员账号去点了教练端的接口、或者预约了一个已经过期的时段这些细节到位了项目自然就站得住脚。