说是管理系统，其实这种讲座预约系统做起demo来不难，但真要拿到真实校园环境里跑，坑一个比一个深。我帮某高校信息中心做过一版这样的系统，从需求梳理到上线前后打磨，前后折腾了差不多三周。这篇就把整个“Spring Boot高校学习讲座预约管理系统”的设计思路、核心实现、踩坑经历全部拆开讲，项目不算大，但涵盖的点很全，适合正在做课程设计、毕业设计，或者是想完整走一遍Spring Boot业务系统开发流程的同学参考。
这个项目核心要解决的事情很明确：把讲座发布、学生预约、签到统计这一整套流程线上化。过去线下预约靠班长统计、现场签到靠手写，数据乱、统计慢、冲突多，讲座上座率也没法预估。系统上线后，管理员发讲座、学生在线抢名额、到了现场扫码签到，所有数据自动沉淀，不仅能看谁来了谁没来，还能按讲座维度分析到场率。对于开发来说，一个预约系统里恰好覆盖了权限控制、核心业务流转、并发处理、定时任务、数据统计等多个经典模块，练手价值很高。
1. 需求拆解与技术选型的底层逻辑
1.1 从用户角色反推系统边界
做这种系统最忌讳一上来就写代码。真实的校园讲座场景里，至少牵扯三类角色。
- 系统管理员：维护讲座分类、审核讲座发布、管理用户、查看全系统预约数据和统计报表。
- 讲座发布人：通常是辅导员、学生会干事或各学院的教务老师，负责创建讲座、设置名额和预约时间窗。
- 学生用户：看讲座列表、查看详情、预约、取消预约、现场签到。部分学校还要求讲座学分，那还需要“参加记录”作为凭证。
需求梳理清楚后，系统的功能模块基本就定了。我当时把功能域切成五块：用户认证与权限、讲座信息管理、预约流程管理、签到与统计、系统基础配置。每一块再往下拆，比如“预约流程管理”里就包含预约名额校验、冲突检测、取消预约的配额回补、预约状态流转。这样拆完，数据库设计和接口设计才有据可依。
1.2 为什么选择Spring Boot而非其他方案
选Spring Boot，我的理由很直接：生态成熟、开发效率高、部署不折腾。项目用Spring Boot 2.7.x，搭配MyBatis-Plus做数据访问，Spring Security处理认证授权，Redis承担缓存和分布式锁，MySQL 8.0做数据持久化。前端第一版用Thymeleaf服务端渲染快速搞定，上线后再迭代成了前后端分离，但核心逻辑没动，这也是Spring Boot的天然优势。
很多同学纠结SSH还是Spring Boot，我建议直接Spring Boot。SSH那套XML配置繁琐，新项目没必要再用。Spring Boot的自动配置把大量样板配置消掉了，内置Tomcat能打成单Jar包直接跑，对部署环境不友好的校园内网来说特别省心。我们需要做的只是定义JPA或MyBatis的实体映射、写业务Service，然后关注核心规则。
技术选型里还要解释一个问题：为什么配Redis？讲座预约的核心矛盾是并发抢名额，纯靠数据库行锁也能跑，但高峰期数据库连接容易被占满，接口响应变慢。中间加一层Redis做前置名额预扣，可以明显减轻数据库压力。至于具体怎么扣，后面单独讲。
注意：如果只是想快速完成一个课程设计，去掉Redis，直接用数据库乐观锁也能交差。但真实项目里并发量上来后，没有缓存层基本撑不住，两个方案我都在文里写清楚。
2. 系统架构与数据库设计的核心思路
2.1 分层架构是怎么定的
我采用标准的三层架构：Controller层负责参数接收和响应封装，Service层写业务规则，Mapper层做数据访问。额外加了一个handler包来处理全局异常和参数校验异常，一个config包放安全配置和Redis配置，一个util包放JWT工具类、日期处理工具类。
很多人觉得分层是教条，但在这个项目里，分层带来的收益是实打实的。举个具体例子，预约成功后要发通知，如果通知逻辑写在Controller里，那之后加个“预约成功赠送资料包”的功能就得改接口。放到Service层里就能在同一个事务中保证业务原子性，后续扩展也只在Service内增加步骤，不影响接口签名。
实体类设计与数据库表一一对应。核心表包括：
sys_user（用户表）lecture_info（讲座表）lecture_category（讲座分类表）reservation_record（预约记录表）checkin_record（签到记录表）lecture_statistics（统计汇总表，可选）
2.2 数据库字段设计与取舍经验
讲座表lecture_info是最核心的表，字段比较多，我把关键字段列出来：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| title | varchar(100) | 讲座标题 |
| speaker | varchar(50) | 主讲人 |
| lecture_time | datetime | 讲座开始时间 |
| location | varchar(100) | 地点 |
| total_quota | int | 总名额 |
| reserved_count | int | 已预约人数，冗余设计 |
| status | tinyint | 草稿0/已发布1/已结束2/已取消3 |
| checkin_start_time | datetime | 签到开始时间 |
| checkin_end_time | datetime | 签到截止时间 |
| create_by | bigint | 发布人ID |
| version | int | 乐观锁版本号 |
reserved_count这个字段是典型的冗余字段，它存储已预约人数，每次预约成功就加一。设计时坚持用一个字段而不是COUNT(*)实时统计，理由很现实：讲座列表页要高频显示剩余名额，如果用聚合查询，数据量大了以后列表接口的响应时间会明显变长。只读冗余字段，写入时维护，读多写少的场景性价比最高。
预约记录表reservation_record，重点设计的是状态机和唯一约束。
user_id和lecture_id组合加唯一索引，防止同一用户对同一讲座重复预约。status字段：已预约1/已取消2/已签到3/已过期4。reserve_time记录预约时间，后续用于排队或者统计峰值。
我特意埋了一个is_valid字段而不是直接物理删除记录。用户取消预约后，那条记录仍保留并标记状态，一方面是为了后续做“预约后又取消”的行为分析，另一方面保留完整流水，方便和出勤率对照。
2.3 为什么演示系统也要设计表间关系
设计表的时候最容易被忽略的是外键约束问题。一些演示性的项目为了图省事，表之间不建外键，所有关联全靠代码控制。前期的确省事，但真查起数据来会很痛苦。
我的做法是：数据库层面不建物理外键，因为会拖慢插入性能、增加死锁风险。但会在reservation_record上建索引，并在Service层强制校验讲座是否存在、分类是否有效。这样既保证了效率，又能通过代码强制数据完整性，也是业界的主流做法。
另外设计表时加上create_time和update_time两个公共字段，所有表共用，后面做统计报表直接按创建时间分组，不用再回改表结构。
3. 核心功能模块实现与业务规则设计
3.1 用户认证与权限控制
认证方案用的是JWT，配合Spring Security做接口级权限控制。流程上：
- 用户用学号/工号和密码登录
- 登录成功后后端签发JWT，把用户ID、角色类型放进去
- 前端把Token存到本地存储，每次请求放在请求头里
- 后端拦截器校验Token有效性，并解析出当前用户信息
权限控制上，不需要复杂的RBAC模型。校园场景就三种角色，管理员、发布人、学生。我在Spring Security里用@PreAuthorize注解做粗粒度控制，再在Service里做细粒度数据权限校验。
一个常见坑点：JWT在Spring Boot中处理时，请求头中Token为空或者过期，拦截器直接返回401。但前端页面有时候没跳转到登录页。这个问题建议在全局异常拦截器中对认证异常做统一捕获，返回Code 401，前端统一的HTTP拦截器检测到后清理本地凭证并跳转登录。
另外，密码存储必须用BCrypt加密，绝对不能明文。我见过一个内部系统，数据库里全是明文密码，虽然内网风险小，但这习惯真的很不好。Spring Security自带BCryptPasswordEncoder，几行代码就集成好了。
3.2 讲座发布与生命周期管理
这一块核心是状态机设计。我设定讲座的生命周期：草稿 -> 已发布 -> 已结束/已取消。
- 创建讲座默认是草稿状态，只有编辑补充完整之后手动发布。
- 讲座开始时间晚于当前时间，才能发布。
- 已发布的讲座可以修改信息，但修改名额时必须做限制，不能小于当前已预约人数。
- 讲座开始后自动不可预约，但签到仍然开放。
- 管理员可以取消未开始的讲座，取消后所有预约记录置为无效，名额自动释放。
发布的时候还要做时段冲突校验，我当时踩了个坑：同一场地在同一时间段不能安排两场讲座，但校内场地资源很紧张，经常出现同一个教室同一时间被申请两次。解决的方案是加了一张venue_schedule表，在保存讲座时做时间段交叉查询。SQL里判断条件是：
SELECT COUNT(*) FROM lecture_info WHERE location = #{location} AND status IN (1, 2) AND lecture_time < #{endTime} AND DATE_ADD(lecture_time, INTERVAL duration_minute MINUTE) > #{startTime}这个SQL的核心逻辑是两个时间段交叉：已有讲座的开始时间早于新讲座的结束时间，且已有讲座的结束时间晚于新讲座的开始时间，那就冲突了。这个判断初看有点绕，但其实是区间重叠判断的标准写法，比单调比较startTime或endTime要完整得多。
3.3 预约流程的状态流转与校验链
预约是系统的核心链路，状态流转我画得很清楚：
未预约 -> 预约成功 -> 已签到 / 已取消 / 已过期
每次预约请求进来，Service层按顺序做五步校验：
- 校验讲座是否存在且状态为已发布。
- 校验当前时间是否在预约时间窗口内。
- 校验用户今天是否已经预约过该场次（走唯一索引）。
- 校验用户是否有讲座冲突，也就是同一时间段已预约了别的讲座。
- 校验剩余名额是否充足。
第五步是并发问题的集中爆发点。如果不用锁，两个用户同时请求，都看到剩余名额1，都能通过校验，最后超卖。这是典型的“查询再更新”竞态问题。
我的解决方案分两层：
- 第一层，Redis预扣减名额。用
decrement操作把剩余名额扣掉，decrement返回值小于0说明名额已经扣完，直接返回“名额不足”。这一步把压力从数据库转移到了Redis。 - 第二层，数据库更新时加条件。
UPDATE lecture_info SET reserved_count = reserved_count + 1 WHERE id = ? AND reserved_count < total_quota，这一步即使Redis出现了不一致，数据库层也会兜底。
这里还要考虑一个细节：扣了Redis名额之后，如果后面业务校验失败，必须回补Redis名额。我用Redis事务保证decrement和业务执行之间的一致性，避免大量失败请求把有效名额吞掉。
3.4 签到逻辑的设计
签到逻辑可以用二维码实现，但在真实校园场景中要考虑一个实际困难：学校教室的网络未必稳定，生成二维码依赖网络请求，学生扫码也依赖网络。我最终的做法是生成一个六位签到码，固定有效时间三分钟，讲座开始时投屏展示。学生输入签到码即可完成签到。
签到码存在Redis中，设置过期时间，存的key是checkin:code:{lectureId}，value就是随机六位数字。学生提交签到码后比对Redis值，一致则把预约记录状态改为已签到，同时写入签到时间。
签到时间窗口的判断也很关键，不能让学生提前几个小时就签到了。我在lecture_info上设置了checkin_start_time和checkin_end_time，Service层先判断当前时间是否在窗口内。讲座结束后仍然可以补签，但必须由管理员手动操作。
4. 并发预约、缓存与消息通知的工程化落地
4.1 并发预约的锁设计，超卖问题如何彻底解决
讲座预约场景的并发量，热门讲座往往开抢前就有几千人等着。比如请了一个知名专家，名额却只有两百个，那开抢瞬间的QPS可能几百甚至上千。如果所有请求都打到数据库，行锁会让大量线程阻塞，甚至拖垮数据库。
因此我做了两级限流和两层防超卖体系。
- 前置拦截：按用户维度做接口限流，Redis中使用固定窗口计数器。同一用户在一秒内最多请求十次预约接口，超出直接拒绝。
- Redis预扣：预约名额存Redis，key是
lecture:quota:{id}。预约先走decrement，扣减成功后继续业务处理。 - 数据库条件更新兜底：不管Redis扣得多顺，数据库永远用条件更新，
reserved_count < total_quota，保证最终一致。 - 回补机制：业务校验失败或者用户主动取消时，Redis和数据库同步回补名额。
这套方案下来，实测两千人同时抢一场三百个名额的讲座，接口正常完成，无超卖。
关于锁粒度，我再补一个经验：没必要对整个预约过程加分布式锁。锁的粒度越小，系统吞吐量越高。真正的临界资源只有“剩余名额”，所以只对扣减名额这个动作做原子操作即可。如果锁住整个预约检查链路，预约响应时间会明显变慢，用户体验不好。
4.2 Redis缓存的使用边界
Redis在系统里不是万能的，我最开始想把所有讲座列表都缓存，结果发现每次发布新讲座、修改讲座信息、名额变动都要删除缓存，一致性问题很麻烦。后来界定了缓存的边界：
- 讲座详情：变更不频繁，缓存5分钟，读取压降明显。
- 预约名额：实时性要求极高，直接读写Redis，不设置过期时间。Redis异常时兜底走数据库。
- 签到码：时效强，设置三分钟过期。
- 用户会话：JWT是无状态的，所以用户信息不存Redis，靠Token解析。
分布式锁我用Redisson实现，主要是看中它的看门狗机制，不用手动续期。如果项目里没引Redisson，用SETNX加过期时间也可以，就是要自己处理锁续期，过期时间太短业务没执行完锁就释放了，太长又可能长时间阻塞其他线程。这一块写的时候要特别注意。
4.3 消息通知的设计：从事件回调到定时轮询
预约成功要不要发通知？讲座开始前要不要提醒？真实场景里这个需求是高频的。我的实现没有引入消息队列，而是直接用Spring Boot的事件机制。
预约成功后发布一个ReservationSuccessEvent，监听器里负责发送站内信和邮件。这样的好处是异步解耦，预约主链路不需要等邮件发送完成。Spring的@Async配合@EventListener用起来很方便，但要注意异步线程池的配置，默认的SimpleAsyncTaskExecutor每次新建线程，并发高时很糟糕。我配置了一个核心线程数10、最大线程数50、队列容量200的线程池，够用了。
定时任务用来处理讲座开始前的提醒。Spring的@Scheduled每五分钟扫一次lecture_info表，找出“即将开始且状态为已发布”的讲座，给所有已预约用户发提醒。这里要控制扫描范围，加个条件只扫未来一小时内的讲座，避免全表扫描。
注意：定时任务要加分布式锁。如果未来系统部署了多个实例，同一个五分钟任务会在不同机器上重复执行，导致重复发送提醒。最简单的方法是用Redis的
setnx抢锁，抢到锁的实例才执行本轮任务。我踩过这个坑，上线第二天就有学生反映收到三条重复提醒。
5. 代码落地：工程结构、关键代码与配置明细
5.1 工程目录结构与核心依赖
工程用Maven构建，Spring Boot版本2.7.14。核心依赖如下：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency>工程目录：
com.example.lecture ├── config │ ├── SecurityConfig.java │ ├── RedisConfig.java │ └── AsyncConfig.java ├── controller │ ├── AuthController.java │ ├── LectureController.java │ └── ReservationController.java ├── service │ ├── LectureService.java │ ├── ReservationService.java │ ├── CheckinService.java │ └── StatisticService.java ├── mapper │ ├── LectureInfoMapper.java │ └── ReservationRecordMapper.java ├── entity │ ├── LectureInfo.java │ ├── ReservationRecord.java │ └── SysUser.java ├── handler │ ├── GlobalExceptionHandler.java │ └── AuthExceptionHandler.java └── util ├── JwtUtil.java └── RedisKeyUtil.java5.2 预约Service的核心代码
预约是系统的核心，代码我简化后贴出框架，大家可以对照思路：
@Service public class ReservationService { @Autowired private StringRedisTemplate redisTemplate; @Autowired private LectureInfoMapper lectureInfoMapper; @Autowired private ReservationRecordMapper reservationRecordMapper; @Transactional(rollbackFor = Exception.class) public Result reserve(Long userId, Long lectureId) { String lockKey = RedisKeyUtil.reserveLock(userId, lectureId); boolean tryLock = redisTemplate.opsForValue() .setIfAbsent(lockKey, "1", Duration.ofSeconds(3)); if (!tryLock) { return Result.error("操作过于频繁，请稍后再试"); } try { LectureInfo lecture = lectureInfoMapper.selectById(lectureId); // 各种业务校验... if (lecture.getStatus() != 1) { return Result.error("讲座不在预约状态"); } // 唯一索引防重，预约记录表里不存在有效记录 Integer existCount = reservationRecordMapper .countValidReserve(userId, lectureId); if (existCount > 0) { return Result.error("请勿重复预约"); } // Redis预扣名额 Long remain = redisTemplate.opsForValue() .decrement(RedisKeyUtil.lectureQuota(lectureId)); if (remain < 0) { redisTemplate.opsForValue().increment(RedisKeyUtil.lectureQuota(lectureId)); return Result.error("名额不足"); } // 数据库条件更新兜底 int rows = lectureInfoMapper.deductQuota(lectureId); if (rows == 0) { redisTemplate.opsForValue().increment(RedisKeyUtil.lectureQuota(lectureId)); return Result.error("名额不足"); } // 保存预约记录 ReservationRecord record = new ReservationRecord(); record.setUserId(userId); record.setLectureId(lectureId); record.setStatus(1); record.setReserveTime(new Date()); reservationRecordMapper.insert(record); // 发布预约成功事件 applicationEventPublisher.publishEvent( new ReservationSuccessEvent(this, userId, lectureId)); return Result.success("预约成功"); } finally { redisTemplate.delete(lockKey); } } }事务上加rollbackFor = Exception.class是必须的。Spring默认只在RuntimeException时回滚，如果Service内抛出受检异常，事务不生效，数据就可能出现半成品状态。这种坑很难查，细节决定成败。
数据库扣减名额的SQL，写在Mapper里：
<update id="deductQuota"> UPDATE lecture_info SET reserved_count = reserved_count + 1 WHERE id = #{lectureId} AND reserved_count < total_quota </update>5.3 Spring Security配置要点
Security配置里，我区分了两个维度：
/api/auth/**放行/api/lecture/list、/api/lecture/detail放行给游客浏览- 其他所有接口都需要认证
/api/admin/**要求管理员角色/api/publisher/**要求发布人角色
配置代码框架：
@Configuration @EnableWebSecurity public class SecurityConfig { @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.csrf().disable() .sessionManagement() .sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeRequests() .antMatchers("/api/auth/login").permitAll() .antMatchers("/api/lecture/list").permitAll() .antMatchers("/api/admin/**").hasRole("ADMIN") .anyRequest().authenticated(); http.addFilterBefore(jwtAuthFilter, UsernamePasswordAuthenticationFilter.class); return http.build(); } }Spring Security 5.7之后WebSecurityConfigurerAdapter已经废弃了，用SecurityFilterChainBean的方式配置是官方推荐的。改版才一年，很多人还在抄旧代码，运行时会报错。用Spring Boot 2.7以上的版本务必注意这一点。
5.4 前端页面的交互设计
第一版用Thymeleaf做服务端渲染，页面包含首页、讲座列表、讲座详情、个人中心、管理后台。核心交互就两个：
- 讲座详情页显示实时剩余名额，点击“立即预约”按钮。按钮的状态根据登录态、预约截止时间、是否已预约自动切换。
- 管理后台编辑讲座，设置名额和时间窗口。
后来迭代成Vue前后端分离时，这些交互逻辑基本没变，只是把剩余名额的展示改成轮询或WebSocket推送。坦白说，讲座预约这种低实时性场景没必要上WebSocket，刷新页面或者按钮点击时重新拉取数据就够用。我见过给预约系统硬上WebSocket的项目，纯属给自己找麻烦。
前后端分离版本的权限控制仍然依赖于后端接口校验，前端路由守卫只是提升体验，真正的安全边界一定在后端。
6. 常见问题排查与优化实录
6.1 高频问题速查表
下面的表是我实际运维时遇到的问题汇总，可以直接抄作业排查：
| 问题现象 | 排查思路 | 解决方式 |
|---|---|---|
| 预约成功后名额没减少 | Redis扣减了但数据库更新行数为0，大概率事务没提交或讲座状态被改 | 检查Service事务注解和SQL条件 |
| 用户重复预约成功 | 唯一索引未建或预约记录校验漏了状态条件 | 建联合唯一索引，并过滤已取消状态的记录 |
| 讲座列表加载慢 | 名额统计走聚合查询，数据量变大后变慢 | 改成冗余字段，或者加Redis缓存 |
| 定时提醒重复发送 | 多实例部署没有抢分布式锁 | 用Redis的setnx实现任务抢占 |
| 签到码不生效 | Redis中key过期时间太短或时区不对 | 统一使用服务器时区，签到码有效期设为三分钟 |
| 取消预约后无法再次预约 | 前端只改了状态，数据库里预约记录没有同步回补 | 取消流程必须同步回补名额并更新记录状态 |
| 讲座修改名额后预约异常 | 修改名额时没校验已预约人数 | 加校验，名额数必须大于等于已预约数 |
6.2 性能调优的真实数据
上线后我对预约接口做了压测。机器配置是四核八G，单实例部署，数据库在同一台服务器上。
不加Redis时，两百并发预约，接口平均响应时间约380毫秒，数据库CPU占用到70%，出现少量超时。加上Redis预扣后，同样两百并发，平均响应时间降到90毫秒左右，数据库CPU降到30%。
这里的关键不是Redis本身有多快，而是把数据库的写压力从“每次都Update行”变成了“只有业务校验通过才Update一次”。大量抢不到名额的请求在Redis层就被拦截了，根本不会打到数据库。
业务的优化没有止步于此。我后续又把讲座详情页查分类的SQL加了索引，把列表接口的分页查询改成只查必要的字段。首页接口响应时间从600毫秒降到了150毫秒。这些优化的共同原则是：先定位瓶颈，再加缓存，再加索引，不要一上来就无脑加Redis。
6.3 项目复盘：如果重新做一次会在哪里改进
有几点我的体会很深。
- 第一，数据库表设计阶段就要考虑逻辑删除和唯一索引的组合问题。物理删记录和逻辑删除混用的场景很容易留下脏数据，我在上线前清理用户测试数据时就发现预约记录存在大量孤儿数据，清洗成本很高。
- 第二，日志规范从一开始就要定好。预约流程是核心链路，每一步的入参、校验结果、扣减结果都要打日志。我一开始只在异常时打日志，导致线上排查超卖问题时完全没法回溯。后来补了关键路径的日志，排查效率翻倍。
- 第三，如果重新做，我会在架构层面多预留一个消息队列的位置。目前站内信和邮件通知用事件机制是可以的，但后续如果要接企业微信、短信等多渠道，事件监听器会逐步膨胀，不如用消息队列做统一出口。不过对课程设计和毕业设计而言，事件机制已经够了。
7. 部署与后续扩展：从Demo到可上线
7.1 部署环境准备与打包
打包部署是整个项目里最容易翻车的一环。这个项目我用了Maven的profile区分开发环境和生产环境。
在application.yml里抽取公共配置，application-dev.yml配置本地数据库和本机Redis，application-prod.yml配置服务器IP、数据库账号密码等敏感信息。打包时指定环境：
mvn clean package -DskipTests -Pprod然后直接运行：
java -jar lecture-system.jar --spring.profiles.active=prod生产环境部署时有两个关键坑：
- 一是必须配置JVM参数，限制堆内存。不配置的话默认堆大小可能占到机器内存的四分之一，小服务器直接内存溢出。
- 二是MySQL连接串务必加上时区参数
serverTimezone=Asia/Shanghai，否则日期字段会差八个小时。这个坑几乎人人都踩过，我也不例外。
推荐的生产部署命令：
java -Xms256m -Xmx512m -jar lecture-system.jar \ --spring.config.location=/etc/lecture/config/application-prod.yml \ --spring.profiles.active=prod7.2 后续扩展方向
如果把系统交到学校信息中心，几个扩展方向可以推进：
- 对接统一身份认证。学生账号通常来自统一身份认证平台，预留好OAuth2接入点，避免重复维护账号体系。
- 增加讲座回放或直播的入口。线上讲座逐渐成为常态，预约后自动关联直播链接，签到逻辑也需要对应调整。
- 增加学分管理。部分学校要求讲座学分，预约和签到数据对接学分系统，实现自动换算。
- 提供数据大屏。信息中心领导要看全局数据，统计讲座总数、参与人次、到场率，甚至按院系维度下钻。
这些扩展都建立在当前系统数据模型完整、预约记录流水可追溯的基础上。所以前面强调的“预约记录不要物理删除”，就是为了这一步做铺垫。
8. 写在最后的几句实在话
这个项目让我印象最深的一次复盘，不是功能开发，而是上线前自测发现的一个问题。我模拟两个用户同时抢最后一个名额，结果两个人都提示“预约成功”，而数据库里实际只插入了一条记录。原因很简单——Redis预扣和数据库扣减之间没有做最终一致性校验，一个用户扣了Redis名额后业务校验通过但在插入预约记录时抛了异常，事务回滚了数据库，Redis却已经扣掉名额了。另一个用户看到Redis剩余名额充足，直接走了数据库条件更新，结果数据库也剩一个名额，就成功了。两个用户都成功，但数据库只有一条记录，说明Redis和数据库的数据在极端情况下出现不一致。
后来我把数据库扣减和插入预约记录放在同一个事务中，并且把Redis扣减改为事务提交后再异步写入，最终消除了这个问题。解决办法并不复杂，但要小心每一步操作之间的时间窗口。这类问题在单体应用里就已经很隐蔽了，换成微服务环境只会更难排查。
如果你也正在做类似的Spring Boot管理系统，我的建议是：把重点放在核心业务链路的完整性和数据一致性上，而不是堆砌花哨的界面。预约系统的灵魂是“谁能约、怎么约、约完怎么记”，前端再好看，后台逻辑一团糟，上线就是事故。
最后分享一个小经验，排查预约类业务的并发问题时，最好的工具不是日志也不是Debug，而是明确的状态流转图。把每一步的输入、输出、异常分支都画清楚（哪怕画在纸上），代码写起来才不会有模棱两可的地方。我做这个项目时，光预约流程的状态流转图就修订了三版，每一版都发现一个之前没考虑到的边界情况。好系统真的是改出来的，不是一次写出来的。
