第一次接触驾校管理系统时我本能地觉得这不就是个课程表加用户管理吗把教练、课程、学员三张表建好写几个CRUD接口就算交付了。真正动手之后才发现基于SpringBoot的学车驾校线上学习课程安排管理系统里最耗心力的部分根本不是CRUD本身而是排课这类带约束条件的资源调度问题。教练的可用时段、学员的空闲时间、场地的容量、课程的科目类型任何一个维度没想清楚线上排课就会复现线下Excel排课的老毛病。这篇文章我围绕模拟项目X从需求梳理到数据库建模、核心业务实现、权限控制的过程展开并把我实测中踩过的并发预约和日期解析的坑一并写出来希望给正在做同类课程设计或毕业设计的同学一条可以直接参考的路线。1. 排课业务梳理这个系统真正要解决的是什么1.1 线下排课的效率与冲突问题先说说这类系统要替代的真实场景。传统驾校的排课流程大致是这样教务管理员手里拿着一张Excel排课表把一个教练未来两周的空闲时段一格一格填进去然后再看哪些学员这个时间有空逐个电话通知。听起来只是繁琐了一点实际操作中有三个问题很容易爆发。第一教练资源被重复占用。一个教练一天能带6到8个课时但Excel表格没有约束逻辑管理员填课时稍微不留神同一时段就可能填给两批学员等到上课当天才发现撞车再临时调课整个教学计划全部被打乱。第二名额信息传递靠人工。学员想知道某个科目实操还剩几个名额必须通过电话或微信问前台前台查表、查看、再回复过程慢不说还容易出现刚刚还剩2个等你订的时候已经满了的情况。第三课程变动的通知成本很高。教练临时有事要调课管理员得重新排列时段再挨个通知已经预约的学员如果学员没看到通知第二天直接跑来上课又是一场纠纷。1.2 三类用户的实际诉求与功能边界所以这个系统的需求分析不能只从做一个网页出发而要站在三类用户的真实使用场景上倒推功能。管理员需要教务管理能力维护教练信息按科目创建课程类型发布一段时间内的排课计划查看每个排课时段的预约人数处理学员的取消或改约请求还要能统计教练的课时量。教练需要课表确认能力登录后能看到自己未来几天的排课列表每节课具体在哪个场地、哪个时间段、来了几个学员开课前后可以确认课时状态系统因此能实时反馈给管理员。学员需要在线预约能力注册登录后浏览课程安排按日期、科目、教练筛选可约时段看到剩余名额后一键预约预约成功后在我的课表中查看上课计划也能在规则允许的时间窗口内取消。这三类诉求相互关联催生了系统里最核心的实体——排课记录。简言之所有功能都是围绕某个教练在某个时段带某几个学员上某门课这一件事展开的。1.3 线上学习与课程安排的落地口径从标题看线上学习课程安排容易被理解成在线视频学习平台但课程设计里一般不会做视频上传、播放、进度跟踪这类重功能。更常见的口径是课程安排线上化——把课程信息、科目详情、排课计划、预约流程从线下搬到线上线上学习辅助化——管理员在课程类型里挂课程简介和学习资料入口学员报名后可以查看对应科目的学习说明。把边界划清楚很重要否则你会在需求评审时陷入要不要支持视频播放的争论最后把排课主流程挤得变形。我的建议是核心做预约与排课线上学习只做信息展示和资料入口视频学习等能力可以通过外链或后续扩展来实现不影响主流程验收。2. 技术选型与工程落点为什么是SpringBoot2.1 框架对比从SSM到SpringBoot的减负逻辑早年的课程设计项目常见组合是SSH或者SSMSpringMVC加Hibernate/MyBatis还要写一大堆XML配置。数据源、事务管理器、视图解析器、包扫描每一步配置错了都是启动期的灾难。到了SpringBoot时代自动配置把大部分样板代码接管了内嵌的Web容器让你不需要单独部署Tomcat打一个可执行Jar包直接就能跑起来。对于课程设计项目来说SpringBoot还有两个更实际的收益。一是资料多遇到问题搜索到的解决方案基本都是这个技术栈二是开发节奏快从空项目到能跑通增删改查半天时间都用不到可以把精力集中在业务逻辑上。这不是说SSM不能做而是SpringBoot让复杂度和开发效率之间的性价比更高。2.2 前后端分离下的包结构与分层职责这个项目我采用的还是前后端不分离的传统结构页面用Thymeleaf模板渲染后端按Controller、Service、Mapper三层分包。这样做的原因很简单课程设计项目通常需要演示完整页面传统模板渲染能少搭一套前端工程部署和答辩都更省事。典型的包结构是这样com.example.driving ├── controller // 接口层接收请求返回视图或JSON ├── service // 业务逻辑层 │ └── impl ├── mapper // 数据访问层 ├── entity // 数据库实体类 ├── dto // 前端交互对象与实体解耦 ├── common // 统一返回、异常、常量 ├── config // 拦截器、事务等配置 └── utils // 日期、校验等工具类分层的核心原则是Controller不写业务逻辑只做参数接收、校验和视图路由Service承载事务与业务规则Mapper只负责数据读写。这样划分之后后面加权限拦截、加事务控制都能找到清晰的落点。2.3 数据访问层选型MyBatis-Plus还是JPA数据访问层我推荐MyBatis-Plus理由有三点。第一它保留了MyBatis的SQL可控性复杂统计可以直接写XML不用跟JPQL较劲。第二内置的Wrapper查询语法很简洁像按日期筛选排课列表这种操作一行LambdaQueryWrapper就能写完减少重复的SQL模板代码。第三它的逻辑删除、自动填充、分页插件都是开箱即用对课程设计项目足够友好。JPA当然也可以但对于排课冲突检测这类需要精确控制SQL的场景JPA的实体映射和懒加载反而会增加心智负担。选好MyBatis-Plus之后数据库表结构设计得合理后面的开发会顺畅很多。3. 数据库建模六张核心表与排课状态机3.1 核心表的字段设计与关系数据库是整个系统的地基表结构没设计好后面写代码就是不停地打补丁。这个项目我最终保留了六张核心业务表外加用户表和日志表表名核心字段作用userid, username, password, role, phone登录账号与角色student_infoid, user_id, real_name, id_card, study_no学员档案coach_infoid, user_id, name, driving_age, teach_age, subjects教练信息course_typeid, name, category, hours, description, study_url课程类型course_scheduleid, coach_id, course_type_id, schedule_date, start_time, end_time, location, max_count, booked_count, status排课核心表enrollmentid, schedule_id, student_id, enroll_time, status, cancel_time预约记录这里最关键的是course_schedule它把教练、课程、时间、场地、容量聚合成一次具体的排课。enrollment表则是一份预约单记录哪个学员预约了哪次排课。两表通过schedule_id建立多对一关系一个排课时段可以对应多个学员预约。3.2 排课状态与预约状态的流转规则排课状态不能只设置可预约和不可预约两个值否则业务根本没法还原。我用整数状态表示0 待开始管理员创建后默认状态可被学员预约1 约满已约人数达到最大人数只能等有人取消2 进行中当前时间落在上课区间内不可取消、不可改名3 已完成课程结束由教练确认或定时任务标记4 已取消管理员主动取消或该次排课下所有预约都已取消预约记录本身也有状态0表示已预约1表示已取消2表示已完成。字段cancel_time专门记录取消时间便于后面对频繁取消的学员做规则限制比如一天内取消超过两次就限制当日预约。这里有一个很容易踩的坑已完成和已取消的排课都不能物理删除否则历史统计数据就会断掉。所以表设计里要有逻辑删除标记或者干脆只用status区分真实场景里没人会去delete一条已经上完的课程记录。3.3 时间冲突检测重叠区间的正确写法排课里最容易被写错的是时间冲突判断。很多人一开始会写成两个排课的日期相同且开始时间相同才算冲突但这只覆盖了完全重叠的情况错失了最常见的部分重叠。正确判断两个时间区间是否冲突用这个条件[start1, end1) 和 [start2, end2) 冲突当且仅当 start1 end2 AND start2 end1写成SQL排查某个教练在指定时段是否已有排课是这样的SELECT COUNT(*) FROM course_schedule WHERE coach_id #{coachId} AND schedule_date #{date} AND status IN (0, 1, 2) AND start_time #{endTime} AND end_time #{startTime}注意end_time #{startTime}这半句不能省如果只判断start_time #{endTime}一个早晨8点的排课就可能被晚上6点的新排课误伤。除了教练冲突还要对场地和学员做同样的重叠检测避免同一时间同一地点开两节课或者同一学员同时预约两门课程。实际开发时学员维度的冲突判断通常是在预约时实时查而教练和场地冲突在管理员创建排课时就要查。4. 核心业务流程从管理员排课到学员上课的完整闭环4.1 管理员创建排课数据校验与批量生成排课创建的入口在管理员端页面里需要选择教练、课程类型、上课日期、开始时间、结束时间、场地以及最大预约人数。后端Service接收这些参数后做三件事。第一校验教练时间。用上一节的重叠区间SQL检查该教练当天是否已有排课。第二校验场地冲突。同一个场地的同一天不能同时开两节课。第三查重后进行插入排课状态置为0。如果教练或场地有冲突直接抛出业务异常前端提示管理员更换时间。这里我想补充一个多数课程设计里没做的设计批量排课。比如管理员可以选择每周一、三、五的09:00-10:00连续三周一次生成多条排课记录。批量生成的时间范围扩大了三倍冲突检测的逻辑必须放在循环里逐条校验否则很容易插入一部分后遇到冲突导致数据不完整。实际操作时我建议先生成待校验列表全部校验通过后再统一入库避免中途失败造成脏数据。4.2 学员预约课程名额扣减与防超约学员预约是整个系统里并发压力最大的点。页面显示剩余名额为1时很可能有多个学员同时点击预约所以Service层的预约方法必须做到两个保证名额扣减是原子的预约记录不能重复插入。一个稳妥的实现思路是先做一次学员维度的冲突校验然后在事务里执行条件更新扣减名额再插入预约记录。Transactional(rollbackFor Exception.class) public boolean enroll(Long scheduleId, Long studentId) { // 校验学员当天是否已有排课冲突 if (hasStudentConflict(studentId, scheduleId)) { throw new BusinessException(当天已有课程预约); } // 乐观条件更新只有未满且状态可约时才会更新成功 int rows courseScheduleMapper.bookCourse(scheduleId); if (rows 0) { throw new BusinessException(该时段已被约满); } // 插入预约记录数据库唯一索引兜底防重复 enrollmentMapper.insert(new Enrollment(scheduleId, studentId)); return true; }对应的bookCourse更新语句把条件写在WHERE里UPDATE course_schedule SET booked_count booked_count 1 WHERE id #{scheduleId} AND booked_count max_count AND status 0这条SQL的影响行数为1时说明扣减成功为0时说明要么约满要么状态不对。把校验和更新放到一次SQL操作里就避免了先查后改的竞态问题。外层事务保证如果插入预约记录失败名额扣减也会一起回滚。这条更新逻辑我在后面踩坑章节还会重点复盘它直接决定了系统在高并发下会不会超卖。4.3 教练确认课时状态回流与统计教练登录后看到的是自己专属的排课列表列表按日期排序进行中和待开始的排课显示在醒目位置。开课前半小时教练就可以查看该时段的预约学员名单这比线下拿着纸质名单核对要方便很多。课程结束后教练点击确认完成按钮系统把排课状态从2流转到3同时把该排课下的所有预约记录状态统一置为2已完成。这个动作不是单纯改状态它同时触发两条统计链路教练的课时数增加学员的已学学时也增加。为了数据一致性课程完成的批量更新方法必须放在同一个事务里先更新预约记录再更新排课状态任何一步失败都要整体回滚。5. 权限与越权防护三类角色如何安全隔离5.1 基于自定义注解的接口级权限控制这个系统有三类角色管理员、教练、学员。最简单粗暴的做法是在每个接口里手动判断session中的角色但接口一多代码里全是重复的if判断还容易漏写。考虑到项目采用传统模板渲染登录态用Session管理是更直观的选择不需要额外引入JWT因为我们不需要做跨端身份认证服务端统一管理Session的失效和角色信息就够了。在此基础上我定义一个权限注解让拦截器统一处理。Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequireRole { String[] value(); }在需要管理员权限的接口上标注RequireRole({admin})学员预约接口标注RequireRole({student})然后注册一个HandlerInterceptor在preHandle里读取方法上的注解再结合当前登录用户信息判断是否有权限。这里有一个容易被忽略的细节拦截器里不能只判断用户是否登录因为登录用户可以有三个角色。如果你的接口同时允许管理员查看所有排课和教练查看自己的排课那么要么设计成两个接口要么在Service层里按角色拼装不同的查询条件不要在一个接口里同时返回全部数据再让前端过滤。5.2 越权操作的常见漏洞与封堵方式课程设计项目里最常见的安全漏洞不是SQL注入而是越权。比如学员A通过浏览器开发者工具把请求里的预约ID改成学员B的预约ID如果后端查询时没有带上当前登录用户ID就会把别人的预约取消掉。封堵这类问题的原则很简单所有涉及个人数据的操作都要用当前登录用户ID作为查询条件而不要盲目信任前端传进来的ID。另一个高频越权是学员直接访问管理端接口。前端菜单可以隐藏但接口地址只要被猜到就能调用所以管理端接口必须有后端权限拦截不能只靠页面隐藏。最后数据库表里的敏感字段比如密码保存时一定要加密存储。课程设计阶段用BCrypt加盐哈希就够了不要用明文也不要自定义一个简单加密算法安全评审时这是最容易被打回的一处。6. 实测踩坑记录并发预约与日期时间解析问题全复盘6.1 并发预约同一时间槽从复现到修复的排查链路第一次把预约功能写完我自测时只开了单个浏览器点一次预约成功再点一次提示重复逻辑看起来是好的。后来找了台机器做了并发模拟两个线程同一毫秒预约同一个排课结果数据库里出现了两条预约记录booked_count却只加了1。这个问题的排查链路我完整复述一遍方便你对照排查。第一步复现。用JMeter对一个剩余名额为1的排课发起两个并发请求查看数据库enrollment表发现两条记录都插进去了排课的booked_count从0变成1而实际预约人数是2。这说明先查剩余名额再决定是否更新的判断在并发下完全失效。第二步定位。打开日志逐行对比两个请求都查询到了booked_count max_count都走到了插入预约记录的代码。问题就出在查询和更新之间没有原子性两个请求同时读到相同的旧数据自然都认为还有名额。第三步修复。我先是把Service方法加上synchronized关键字发现单机可以但多实例部署时同步锁只在单个JVM内生效思路不对。随后换成数据库层面的行锁在事务内先SELECT ... FOR UPDATE锁住排课行再执行更新并发冲突被挡住了。最终我采用的是条件更新加唯一索引的组合条件更新保证名额不超卖唯一索引保证同一学员不能重复预约同一排课数据库自己成了最后一道防线。-- 唯一索引同一学员对同一排课只能有一条预约 ALTER TABLE enrollment ADD UNIQUE INDEX uk_schedule_student (schedule_id, student_id);这条唯一索引在实际并发场景里的价值很大。即使条件更新写漏了某种边界情况数据库也会在最后一步拦住重复数据只是错误提示不太友好。所以我在插入预约记录前会先做一次业务判断把数据库约束当作兜底而不是唯一依赖。6.2 日期时间格式混乱引起的解析失败排课表里全是日期时间字段这类问题几乎每个项目都会遇到一次。我踩过最典型的坑是后端用LocalDateTime接收前端传的字符串但默认的JSON序列化规则并不接受2025-06-01 09:00:00这种带空格的时间格式结果前端保存排课时直接报400。修复方式是在实体类的日期字段上统一加注解JsonFormat(pattern yyyy-MM-dd HH:mm:ss) private LocalDateTime startTime;同时为了让接口返回数据的格式稳定配置文件里再设置全局的日期格式化。这里有个经验一个项目里日期格式至少要统一两处一是前端和后端交互的字符串格式二是数据库字段类型和Java类型的映射。建议Java侧统一用LocalDateTime数据库用datetime不要混用Date和Timestamp否则时区问题会在不同环境下随机冒出来。6.3 文档、脚本与代码版本不一致的验收教训这个项目带着万字文档和数据库脚本一起交付但最容易出问题的反而不是代码本身而是文档内容跟不上代码演化。比如最初设计里预约表只有已预约和已取消两个状态后来为了统计学时又加了已完成文档里的状态图却还停留在旧版本。答辩老师按文档提问现场代码行为和文档对不上整个演示的说服力一下就弱了。我的改进做法是代码功能全部稳定后再倒回去更新文档中的ER图、状态流转图和接口说明数据库脚本也按版本号命名v1是建表脚本v2是补充字段脚本这样评审时可以直接看到数据库结构演进过程而不是一份和最终代码脱节的文件。7. 源码、数据库、万字文档课程设计项目如何整理交付物7.1 一套让人快速上手的项目资料应该包含什么很多同学把源码压缩包一丢就以为交付完成了实际上看代码的教务老师或者答辩老师第一天接触这个项目时需要的是快速入门的路径。我的项目资料包里固定放四样东西源码目录、数据库初始化脚本、部署说明文档、设计文档。源码目录里的README必须写清楚三件事JDK版本和Maven版本、启动步骤、默认管理员账号密码。数据库初始化脚本自带几十条演示数据把管理员、教练、学员、课程类型、一周的排课都预置好拿到项目的人运行脚本后不需要手工造数就能看到完整界面效果。设计文档则覆盖需求分析、ER图、核心流程时序、接口说明和测试用例。演示数据还有一个隐藏作用调试接口时不用每次手工构造对象。比如我要测试已约满的排课状态脚本里直接造一条booked_count等于max_count的记录就行比在页面上反复预约再取消高效得多。7.2 答辩与验收前的检查清单最后列一个我在验收前都会跑一遍的检查清单演示环境的数据是否干净旧测试数据是否清理过剩余名额恰好为1的排课并发预约时是否只成功一人学员取消已约满的课程后名额是否立即释放其他学员能否重新预约管理员取消排课学员端我的课表是否同步出现取消标记数据库脚本在一台全新机器上是否一次执行成功文档中的表名字段名是否与实体类完全一致前面几条属于功能正确性最后一条最容易被忽略但影响最直观。答辩演示时老师很可能现场打开数据库看表结构如果脚本和代码对不上前面的演示效果都会打折扣。做完这个项目后我自己最大的体会是课程设计表面上考的是编码能力实际上考的是对业务的理解和工程规范的执行力。排课系统的业务规则不算复杂但状态流转和并发边界想清楚之后整个项目的档次立刻就不一样了。希望这篇记录能帮你把这个系统的每个关键点都提前踩一遍。