企业官网建设流程全解析

前几年带过的一个毕业设计小组里，A同学选的方向就是“高校学习讲座预约系统”。他最初以为只是做个增删改查，结果调研完学院的实际情况才发现，线下讲座预约的混乱程度远超预期：名额靠手速、到场率靠情怀、统计靠Excel。后来他基于Java生态把这套流程完整做成了SpringBoot整合SSM的高校学习讲座预约系统，从需求梳理到表结构设计，从预约并发控制到部署答辩，整个链路走下来收获非常大。这篇文章就是把整个项目从0到1的完整思考、技术选型、核心代码和踩坑复盘做一个梳理，适合刚开始接触SpringBoot实战、正在准备毕设或课程设计的开发者参考，也适合想系统掌握预约类业务模型的Java学习者直接抄作业。

1. 讲座报名场景的痛点拆解：这个系统到底在解决什么问题

1.1 线下预约的管理成本到底有多高

先说一个很真实的场景。高校里的学术讲座、职业规划讲座、课程辅导讲座，消息通常通过班级群、海报栏和公众号推送，学生看到后想报名，往往要填问卷星或者微信群内接龙。这种方式有三层问题。

第一层是对学生不友好。讲座信息零散分布在不同渠道，学生很容易漏掉通知；就算看到了，填完问卷也不知道自己是否报名成功，更不知道名额还有多少。遇到热门讲座，大家同一时间涌入问卷链接，表单崩溃是常有的事。

第二层是对组织者不友好。管理员要手动汇总报名名单，统计学院、年级、专业分布，还要在讲座前后反复发通知提醒到场。讲座结束后，想统计到场率、分析参与偏好，基本要从几十个消息渠道里面人工扒数据。

第三层是系统性问题。没有统一的预约记录，就容易出现重复报名、人员超载、临时占位不来的情况。讲座教室容量明明只有180人，结果问卷收到250份，管理员只能在讲座当天请一部分人回去，体验非常差。

所以当时我们的系统就定下几个核心目标：统一讲座信息发布入口、支持学生在线预约与取消、管理员可审核和管理讲座、自动控制预约名额上限、提供基本的统计报表。这个范围也正好覆盖了一个毕设项目应该有的完整度，既不过度复杂，又能体现数据库设计和业务逻辑设计能力。

1.2 用户角色和功能边界怎么划分

系统权限模型是我们最早确定的部分。整个系统面向三类角色：学生、系统管理员（讲座发布者），以及一个直立的游客概念。游客可以看到公开讲座列表和详情，但预约、取消、查看个人记录都需要登录，这样可以控制未登录状态下的访问压力。

学生端的核心功能包括：注册登录、浏览讲座列表、查看讲座详情、在线预约、取消预约、查看我的预约记录，以及查看讲座相关的通知公告。管理员端的核心功能包括：讲座发布与编辑、讲座上架下架、预约名单查看、预约记录审核或导出、用户管理、讲座类型管理，以及基于时间的预约统计。

这些功能对应到后端，就是用户模块、讲座模块、预约模块、类型模块和统计模块。整个项目的复杂度控制在一个中等水平，非常适合作为SpringBoot整合SSM的教学案例，它把三层架构中Controller、Service、Mapper的分工体现得非常清晰。

1.3 非功能需求同样要提前考虑

我经常看到很多人做系统只关注功能能不能跑通，忽略了非功能需求。但实际项目里，预约系统最怕的恰恰是高峰期一拥而入的并发问题。比如某个热门讲座放出150个名额，几十个学生同时点预约，如果不做控制，预约人数很容易超过容量。

另一个非功能需求是数据安全性。用户密码不能明文存储，至少要用哈希算法处理；接口访问要校验登录状态；管理员操作需要做权限拦截。还有一点容易被忽略：讲座类型、状态这类基础数据要有统一维护入口，不要写死在代码里，否则后期运营人员每次调整都要找开发，很不专业。

这些非功能需求也是后面技术选型时需要重点考量的点。

2. 技术选型的真实考量：SpringBoot整合SSM的边界在哪里

2.1 SpringBoot和SSM到底是什么关系

标题里同时出现SpringBoot和SSM，很多同学第一反应是这两者怎么会放在一起。这里必须先说清楚概念。

SSM指的是Spring + SpringMVC + MyBatis三个框架组合，这是几年前的经典Java Web组合。Spring负责对象管理和事务，SpringMVC负责请求路由和参数绑定，MyBatis负责数据库访问。SpringBoot本质上是一个快速开发脚手架，它并没有取代SSM，而是把Spring生态里各种繁琐的配置自动化了，让你用更少的XML配置就能启动一个SpringMVC工程，同时可以继续使用MyBatis做持久层。

所以我们的技术选型就是：使用SpringBoot作为项目骨架，整合SpringMVC完成请求分发，整合MyBatis完成数据库操作。在很多人嘴里，这种整合方式也会被叫成SpringBoot整合SSM，因为底层仍然是Controller-Service-Mapper的分层思想，只是配置方式从XML转为了注解和自动配置。理解这一点，不仅做项目时不会被概念绕晕，答辩时也能从容解释自己用的是什么。

2.2 持久层用原生MyBatis还是MyBatis-Plus

持久层的选择值得单独说一下。当时A同学在网上看了很多项目模板，发现使用MyBatis-Plus的占比非常高。MyBatis-Plus提供通用Mapper接口，单表CRUD基本不用写SQL，确实能省不少时间。但这不意味着原生MyBatis没有价值。

我的建议比较务实：如果你的项目以预约、讲座这类单表操作为主，且业务逻辑重点在控制业务流程而非复杂SQL，用MyBatis-Plus能快速出成果；但如果你希望通过这个项目证明自己对SQL掌握能力较强，尤其是熟悉连表查询、聚合统计和复杂条件分页，那么原生MyBatis配合XML会更稳妥。

我们最终选择了原生MyBatis，原因有两个。一是预约系统的统计模块需要多表连接查询，比如统计某个月的讲座预约趋势、统计不同学院的参与人数，写XML里的大SQL更能体现细节；二是作为毕业论文项目，使用原生MyBatis去讲解SQL优化和动态SQL，明显比用一个封装好的CRUD工具有更多可写的技术点。

2.3 前端方案：服务端渲染还是前后端分离

前端选型也是个纠结点。服务端渲染的方案可以用Thymeleaf，管理员端配一个开源后台模板，比如基于Bootstrap的AdminLTE这类，开发速度快，部署也简单。前后端分离方案则可以用Vue + Element UI，接口返回JSON，适合单独展示前端能力。

结合时间成本来考虑，如果你的主要精力要放在后端业务上，选Thymeleaf服务端渲染会更稳妥，因为它不需要考虑跨域，也不需要在Node环境里额外调试前端工程。我们当时为了兼顾效果，选择了一个折中方案：管理员后台用Thymeleaf渲染，通过模板继承复用布局；学生端也采用Thymeleaf，配合一些简单的Ajax请求做局部刷新。

这样做的实质是：核心业务页面由后端渲染，保证整站结构完整，预约按钮等操作使用Ajax提交，提升交互体验。这既避免前后端分离带来的跨域和部署复杂度，又比纯表单提交的体验好不少，很适合毕业设计场景。

2.4 辅助组件和技术细节

除了主体框架，还有几个辅助组件要在早期定下来。登录认证我们使用Session配合拦截器实现，简化了JWT的复杂度，同时适合单体应用。密码加密使用BCrypt算法，Spring Security中的BCryptPasswordEncoder可以直接引入，不需要引入整个Security框架。分页使用PageHelper插件，配合MyBatis可以非常方便地完成分页查询。

讲座类型图片、讲师头像这类静态资源，统一放在本地目录，通过一个配置映射为虚拟路径访问。这个细节看似简单，但很多人在部署时因为图片路径写死导致页面裂掉，后面我还会讲到这个问题。

3. 数据库表设计的取舍：预约冲突、并发与统计需求的建模

3.1 核心表结构设计

数据库是预约系统最重要的部分。我根据业务需求设计了下面几张核心表：用户表、讲座表、预约记录表、讲座类型表、公告表。这几张表覆盖了系统的全部核心逻辑，下面把关键字段列出来。

用户表重点字段包括：id、用户名、密码、真实姓名、学号、学院、角色标识、手机号。角色标识用整数区分，1为普通学生，2为管理员。学号和学院字段在统计参与分布时非常重要。

讲座表重点字段包括：id、讲座标题、讲座类型id、主讲人、简介、开始时间、结束时间、地点、容量、已预约人数、状态、创建时间。这里的关键是容量和已预约人数，两者配合控制预约名额。

预约记录表重点字段包括：id、用户id、讲座id、预约时间、状态、签到时间。状态用整数表示：0为已取消，1为已预约，2为已完成。这个表是所有并发控制的核心。

讲座类型表相对简单，就是类型id和类型名。公告表则是标题、内容、发布时间、状态。

3.2 为什么说预约记录表是整个系统的命脉

预约记录表承担的作用远超想象。它不仅是学生预约行为的流水账，更是管理员查看名单、统计到场率、分析参与偏好的数据基础。在设计这张表时，我们特意加了联合唯一约束：在讲座id和用户id上建立唯一索引，确保同一个学生对同一个讲座不能重复预约，这一条能从数据库层面挡住并发下的重复操作。

很多人一开始会忽略这个唯一约束，只靠在业务代码里先查询再判断。但实际场景中，两个请求可能同时通过了查询阶段，然后同时插入预约记录，最终造成数据错误。加上唯一索引后，数据库层面就会拒绝重复插入，后端只要捕获唯一约束异常，给用户返回“你已经预约过该讲座”的提示即可。

3.3 并发控制：不能只靠if判断

预约系统最经典的并发场景就是名额争抢。假设讲座容量为100，当前已预约人数为99，两个学生同时提交预约请求。如果代码写成“先查询当前已预约人数，如果小于容量就执行插入”，两个事务可能同时读到99，然后同时执行插入，最后已预约人数变成101，超过容量上限。

解决这个问题的标准做法是在更新已预约人数时加上容量条件。具体来说，预约时先插入预约记录，再执行一条条件更新语句：

UPDATE lecture SET current_count = current_count + 1 WHERE lecture_id = #{lectureId} AND current_count < capacity

这条SQL的巧妙之处在于，它把容量校验和人数更新放在同一个原子操作里。如果受影响的记录数为0，说明当前已经没有空余名额，业务层就可以回滚事务，提示预约已满。

有的同学会问，如果两个请求同时对同一讲座执行这条UPDATE，会不会都成功？答案是不会。数据库的行锁会保证同一时间只有一个事务能更新这条讲座记录，后进入的事务会等待，等它读到最新数据时current_count已经变成了100，条件current_count < capacity不再满足，更新结果就是0，从而正确判断名额已满。

3.4 签到与取消预约的状态流转

预约状态机的设计也需要提前规划清楚。我们定义了几个状态节点：预约成功、已取消、已完成。学生可以取消尚未来开始的预约，讲座结束后，管理员可以批量将出席的预约记录标记为已完成，或者由系统自动处理。

取消预约时，除了更新预约记录的状态，还要把讲座表的已预约人数减回来。这一步同样要放在一个事务里，否则会导致人数和记录对不上。讲座结束后，需要把有预约记录但实际没有签到的用户标记为缺席，这部分原逻辑我们用了一个定时任务，每天扫描一次，把结束时间早于当前时间且状态仍为已预约的记录，自动批量更新为已完成，并在讲座表里做数据归档。

3.5 统计查询怎么设计SQL

统计功能如果全部靠业务代码在内存里计算，会非常吃力。这里更适合直接用SQL聚合。例如统计最近一个月每日预约数量：

SELECT DATE_FORMAT(create_time, '%Y-%m-%d') AS date, COUNT(*) AS cnt FROM appointment_record WHERE create_time BETWEEN #{startTime} AND #{endTime} GROUP BY DATE_FORMAT(create_time, '%Y-%m-%d') ORDER BY date

又比如统计各学院预约分布，需要连接用户表：

SELECT u.college, COUNT(*) AS cnt FROM appointment_record r JOIN sys_user u ON r.user_id = u.id GROUP BY u.college ORDER BY cnt DESC

这类多表聚合查询在MyBatis的XML里写非常顺手，也能在论文中占据不少技术篇幅。

4. 核心预约流程的代码落地：从拦截器到事务控制的细节

4.1 项目目录结构规划

开工编码前，建议先把包结构调整好。我们最终采用了以下结构，清晰且便于讲解：

com.example.lecture ├── config ├── controller ├── service │ ├── impl ├── mapper ├── entity ├── dto ├── vo ├── interceptor ├── common ├── utils

里面几个容易混淆的点说一下。entity放和数据库表一一对应的实体，dto放接收前端参数的对象，vo放返回给前端展示的对象。很多初学者喜欢一张表用一个类走天下，这在简单页面勉强够用，但像讲座列表需要额外展示类型名称、预约状态这类复合字段时，直接用entity就会很别扭。提前区分开能省不少事。

MyBatis的Mapper接口和XML文件放在同一路径下，或者至少在配置中指定好mapper-locations路径。这是我一直强调的坑，很多人把XML放错目录，启动时报各种找不到语句的错误。

4.2 登录拦截器的设计

因为选择了Session方案，拦截器代码就非常直接。定义一个HandlerInterceptor实现类，在preHandle方法中判断用户是否登录：

@Component public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user = request.getSession().getAttribute("loginUser"); if (user == null) { response.setContentType("application/json;charset=UTF-8"); response.getWriter().write("{\"code\":401,\"message\":\"未登录\"}"); return false; } return true; } }

同时还需要一个管理员权限拦截器，或者在登录拦截器里进一步判断角色。管理端的Controller路径统一以/admin开头，这样拦截器配置就很清晰。在WebMvcConfigurer配置类中注册拦截器，注意排除登录、注册和讲座列表的公开接口：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(loginInterceptor) .addPathPatterns("/**") .excludePathPatterns( "/", "/login", "/register", "/lecture/list", "/lecture/detail/**", "/assets/**", "/css/**", "/js/**", "/images/**", "/user/logout" ); } }

静态资源排除非常重要，否则登录页面也会因为没有登录状态而无法加载CSS和JS。

4.3 学生预约的核心Service逻辑

预约接口是整个系统的业务核心，我贴一段关键代码骨架：

@Service public class AppointmentServiceImpl implements AppointmentService { @Resource private AppointmentRecordMapper recordMapper; @Resource private LectureMapper lectureMapper; @Override @Transactional(rollbackFor = Exception.class) public Result makeAppointment(Long userId, Long lectureId) { Lecture lecture = lectureMapper.selectById(lectureId); if (lecture == null) { return Result.error("讲座不存在"); } if (lecture.getStatus() != 1) { return Result.error("讲座未开放预约"); } if (lecture.getStartTime().isBefore(LocalDateTime.now())) { return Result.error("讲座已开始或已结束"); } AppointmentRecord query = new AppointmentRecord(); query.setUserId(userId); query.setLectureId(lectureId); int existCount = recordMapper.countByUserAndLecture(query); if (existCount > 0) { return Result.error("您已预约过该讲座"); } int updateRows = lectureMapper.increaseCurrentCount(lectureId); if (updateRows == 0) { throw new RuntimeException("讲座名额已满"); } AppointmentRecord record = new AppointmentRecord(); record.setUserId(userId); record.setLectureId(lectureId); record.setStatus(1); record.setCreateTime(LocalDateTime.now()); recordMapper.insert(record); return Result.success("预约成功"); } }

注解@Transactional控制整个方法在一个事务里，任何一步抛出异常都会回滚。increaseCurrentCount对应的SQL就是前面提到的条件更新语句，当更新行数为0时，抛出RuntimeException让事务回滚。

这里有一个很值得答辩时讲清楚的细节：看起来先判断重复预约，再更新名额，再插入记录，似乎存在并发窗口。但有了数据库的唯一约束和条件更新语句，并发安全已经有了底线保障。哪怕两个请求几乎同时进入，唯一的失败路径也能被数据库用异常拦截。

取消预约的Service逻辑类似，需要额外判断取消时间是否早于讲座开始时间。无故取消次数过多的学生，可以在后续版本中加入黑名单限制，作为项目扩展点写进论文。

4.4 讲座管理的事务与时间校验

管理员发布讲座时，需要校验开始时间晚于当前时间、结束时间晚于开始时间、容量大于0。讲座类型也可以通过下拉选择，避免前端随意传字符串导致数据混乱。

发布讲座的流程不止是插入一条讲座记录，还可能要同步生成通知公告。这同样需要放在一个事务中，否则讲座创建成功但公告推送失败，会出现业务状态不一致。代码上可以这样组织：

@Transactional(rollbackFor = Exception.class) public Result publishLecture(LectureDTO lectureDTO) { if (lectureDTO.getStartTime().isBefore(LocalDateTime.now())) { return Result.error("讲座开始时间不能早于当前时间"); } if (!lectureDTO.getEndTime().isAfter(lectureDTO.getStartTime())) { return Result.error("讲座结束时间必须晚于开始时间"); } if (lectureDTO.getCapacity() == null || lectureDTO.getCapacity() <= 0) { return Result.error("讲座容量必须大于0"); } Lecture lecture = new Lecture(); BeanUtils.copyProperties(lectureDTO, lecture); lecture.setCurrentCount(0); lecture.setStatus(1); lectureMapper.insert(lecture); Notice notice = new Notice(); notice.setTitle(lecture.getTitle() + "预约通知"); notice.setContent(lecture.getDescription()); notice.setCreateTime(LocalDateTime.now()); noticeMapper.insert(notice); return Result.success("讲座发布成功"); }

这种多操作事务协同的场景，在论文里写清楚，能明显提升项目的业务完整性评价。

4.5 Controller层返回格式统一

Controller层不建议在每个接口里返回不同类型的对象，最好定义一个统一返回体。我们定义了一个Result类，包含code、message、data三个字段，配合泛型使用。

在讲座列表接口中，还需要额外返回分页信息，比如总数、当前页、每页条数。PageHelper的使用姿势很固定，先设置分页参数，再执行查询，最后用PageInfo包装结果。

PageHelper.startPage(pageNum, pageSize); List<LectureVO> list = lectureMapper.selectLectureList(query); PageInfo<LectureVO> pageInfo = new PageInfo<>(list);

注意PageHelper的坑：startPage必须紧跟第一次数据库查询，中间不能穿插其他数据库操作，否则会导致分页失效。这个坑在下面调试部分还会详说。

5. 高频调试问题复盘：我用这个项目踩过的典型坑

5.1 PageHelper分页失效问题

PageHelper的坑很经典。我们的列表页接口中除了查询讲座列表，还要同时查询讲座类型名称，于是在startPage之后先执行了类型查询，再执行讲座列表查询，结果分页只对第一条查询生效，讲座列表没有被分页。这个问题花了大半天才定位清楚，因为日志里完全没有报错，只是数据返回异常。

正确的做法是保证startPage和要分页的那条查询之间没有任何其他数据库操作，如果要查字典类型，就在分页查询之前先查好，或者将selectLectureList里用连表查询把类型名称直接带出来。我们用连表查询解决了问题，一劳永逸。

5.2 Mapper接口与XML绑定失败

另一个高频问题就是Mapper的XML找不到。很多人把XML放在resources目录下时嵌套路径不对，或者没有在application.yml中配置mapper-locations。启动时看到类似Invalid bound statement的报错，基本就是这个问题。

建议在application.yml里显式指定：

mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.lecture.entity

同时保证XML文件里namespace属性值与Mapper接口的全限定名一致。这个检查项每写一个Mapper接口都值得确认一遍。

5.3 数据库字段与实体属性映射的坑

当数据库字段使用下划线命名，而Java实体使用驼峰命名时，MyBatis的map-underscore-to-camel-case配置可以帮助自动映射。但如果字段是create_time，Java属性是createTime，配置了自动映射基本没问题。

真正容易出问题的是查询结果中使用了聚合函数别名，比如select count(*) as cnt，这个cnt会直接映射到一个没有下划线的字段属性上，只要实体中写了对应的cnt字段就没有问题。有时候别名写得不合规，会导致Java代码读取不到数据，排查时务必先打印日志，不要靠猜。

5.4 事务不生效的隐蔽原因

很多人写了@Transactional却不生效，最常见的原因是同类内部方法调用。比如在一个Service中，方法A调用了本类的方法B，B上有@Transactional，这种情况下事务不会生效，因为Spring的代理机制只对外部调用生效。

解决方式有三种：把需要事务的方法单独放到另一个Service类中；或者在方法A上加上@Transactional，让整个外部入口被代理；或者注入自身的代理对象来调用。我建议在项目初期就约定事务注解统一加在Controller调用的Service入口方法上，避免后期一团乱麻。

5.5 日期时间格式与跨平台问题

前后端日期格式不一致也是常见调试点。后端返回LocalDateTime类型时，默认序列化的格式可能带T，比如2025-06-01T10:00:00，前端页面展示很不友好，而且按时间筛选时格式不匹配常常查不出数据。

解决办法是统一配置Jackson序列化格式。在application.yml中配置：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

同时数据库连接URL中也要加上serverTimezone=Asia/Shanghai，否则在高版本MySQL驱动下会报时区异常。这个细节能让很多无头绪的报错直接消失。

5.6 静态资源图片路径问题

讲座类型和讲师图片上传后的访问路径，是部署阶段最容易出现问题的点。如果图片上传到了项目的target目录下，重新打包后图片会被清空。正确做法是在外部配置一个独立的静态资源目录，比如：

upload: path: D:/lecture-upload/

然后通过WebMvcConfigurer添加资源映射，让/images/**访问到这个外部目录。这样重新部署项目不会丢图片，代码里的引用路径也不会因为项目结构变化而失效。

6. 项目交付的完整拼图：源码、文档与演示讲解如何配合

6.1 源码的工程化组织思路

如果这个项目的标签里包含“源码+LW+调试文档+讲解”，那交付质量就不能停留在能跑通上。源码层面的工程化组织，本身就是答辩时的加分项。

按模块划分包结构，后端主要分config、controller、service、mapper、entity、dto、vo、interceptor、common这些包；前端Thymeleaf模板按管理员端和学生端分目录。数据库脚本单独放在sql目录下，并写出完整的建表语句和示例数据。

代码注释不建议每行都写，而是要在关键方法头部写上业务说明。比如事务方法上的注释写“新增预约记录并同步更新讲座已预约人数，任何异常回滚”，这不仅方便自己后期看，也方便指导老师快速理解设计思路。

6.2 LW文档的写作主线

所谓的LW，通常指的是项目配套的说明文档或论文。写文档时不要机械地复制功能列表，而是要围绕一条主线讲清楚：背景和意义、系统需求分析、系统设计、数据库设计、系统实现、测试结果。

数据库设计部分要给出ER图和核心表结构说明，并解释为什么要设置唯一约束、为什么选择容量条件更新的并发控制方案。系统实现部分要结合核心代码讲实现原理，而不是贴大段代码后什么都不说。测试部分建议写具体的功能测试用例和并发模拟测试，哪怕只是用线程模拟同时请求，也会比空写“测试通过”有说服力得多。

6.3 调试文档应该记录什么

调试文档不是给人看代码的，而是给人看排错思路的。建议按“现象-原因-解决方案-避免方式”的格式记录至少5到10个问题，比如前面提到的PageHelper失效、Session失效、图片路径丢失、事务不生效。

这类记录的价值在答辩时体现得最明显。当老师问“项目遇到过什么难点时”，如果只能回答“没有，都很顺利”，会显得不够真实。但拿出来一两个已解决的实战问题，描述清楚排查链路，答辩的说服力强很多。

6.4 现场讲解的核心讲解路径

讲解演示时不要照着界面从登录开始念功能清单。比较好的演讲路线是：先讲这个系统要解决什么问题，再讲技术选型的考量，然后演示一条完整业务链路，比如学生注册登录、浏览讲座、预约、管理员后台查看名单并结束讲座这一个闭环，最后讲一两个技术亮点，比如容量条件更新和唯一约束保障数据一致性。

演示过程中要准备好几组不同状态的数据，比如还没开始的讲座、已满的讲座、审核中的讲座，方便展示各种分支逻辑。给指导老师留一个好印象的关键，不是你讲了多少功能，而是你能不能说明白每一个核心设计的来龙去脉。

6.5 后续还可以怎么扩展

如果觉得这个项目还有余力，其实有不少扩展空间。比如添加邮件或短信通知服务，在讲座被取消或开讲前提醒学生；引入秒杀场景中的Redis缓存预热，热门讲座发布后把剩余名额缓存到Redis中减少数据库压力；增加学生诚信分体系，预约后多次未到场的学生在下次预约时进行限制。

这些扩展方向在论文的总结与展望部分写出来，会显得你对整个系统的业务思考是完整的。

最后另说一点我在这个项目里最大的感受：所谓预约系统的核心难点，并不在于页面多漂亮，而在于并发场景下数据必须准确。当你在修改数据库状态的同时能意识到它背后隐藏的事务、锁和唯一约束，你的编码认知就上了一个台阶。遇到预约满员返回错误的那一刻，比做出十个普通CRUD页面都有成就感。如果你正在做同类题目，好好对待预约并发控制这个模块，它会是整个项目最值得讲的部分。