说是管理系统其实这种讲座预约系统做起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是最核心的表字段比较多我把关键字段列出来字段名类型说明idbigint主键titlevarchar(100)讲座标题speakervarchar(50)主讲人lecture_timedatetime讲座开始时间locationvarchar(100)地点total_quotaint总名额reserved_countint已预约人数冗余设计statustinyint草稿0/已发布1/已结束2/已取消3checkin_start_timedatetime签到开始时间checkin_end_timedatetime签到截止时间create_bybigint发布人IDversionint乐观锁版本号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_timeService层先判断当前时间是否在窗口内。讲座结束后仍然可以补签但必须由管理员手动操作。4. 并发预约、缓存与消息通知的工程化落地4.1 并发预约的锁设计超卖问题如何彻底解决讲座预约场景的并发量热门讲座往往开抢前就有几千人等着。比如请了一个知名专家名额却只有两百个那开抢瞬间的QPS可能几百甚至上千。如果所有请求都打到数据库行锁会让大量线程阻塞甚至拖垮数据库。因此我做了两级限流和两层防超卖体系。前置拦截按用户维度做接口限流Redis中使用固定窗口计数器。同一用户在一秒内最多请求十次预约接口超出直接拒绝。Redis预扣预约名额存Rediskey是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 groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-security/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.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 iddeductQuota UPDATE lecture_info SET reserved_count reserved_count 1 WHERE id #{lectureId} AND reserved_count total_quota /update5.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配置本地数据库和本机Redisapplication-prod.yml配置服务器IP、数据库账号密码等敏感信息。打包时指定环境mvn clean package -DskipTests -Pprod然后直接运行java -jar lecture-system.jar --spring.profiles.activeprod生产环境部署时有两个关键坑一是必须配置JVM参数限制堆内存。不配置的话默认堆大小可能占到机器内存的四分之一小服务器直接内存溢出。二是MySQL连接串务必加上时区参数serverTimezoneAsia/Shanghai否则日期字段会差八个小时。这个坑几乎人人都踩过我也不例外。推荐的生产部署命令java -Xms256m -Xmx512m -jar lecture-system.jar \ --spring.config.location/etc/lecture/config/application-prod.yml \ --spring.profiles.activeprod7.2 后续扩展方向如果把系统交到学校信息中心几个扩展方向可以推进对接统一身份认证。学生账号通常来自统一身份认证平台预留好OAuth2接入点避免重复维护账号体系。增加讲座回放或直播的入口。线上讲座逐渐成为常态预约后自动关联直播链接签到逻辑也需要对应调整。增加学分管理。部分学校要求讲座学分预约和签到数据对接学分系统实现自动换算。提供数据大屏。信息中心领导要看全局数据统计讲座总数、参与人次、到场率甚至按院系维度下钻。这些扩展都建立在当前系统数据模型完整、预约记录流水可追溯的基础上。所以前面强调的“预约记录不要物理删除”就是为了这一步做铺垫。8. 写在最后的几句实在话这个项目让我印象最深的一次复盘不是功能开发而是上线前自测发现的一个问题。我模拟两个用户同时抢最后一个名额结果两个人都提示“预约成功”而数据库里实际只插入了一条记录。原因很简单——Redis预扣和数据库扣减之间没有做最终一致性校验一个用户扣了Redis名额后业务校验通过但在插入预约记录时抛了异常事务回滚了数据库Redis却已经扣掉名额了。另一个用户看到Redis剩余名额充足直接走了数据库条件更新结果数据库也剩一个名额就成功了。两个用户都成功但数据库只有一条记录说明Redis和数据库的数据在极端情况下出现不一致。后来我把数据库扣减和插入预约记录放在同一个事务中并且把Redis扣减改为事务提交后再异步写入最终消除了这个问题。解决办法并不复杂但要小心每一步操作之间的时间窗口。这类问题在单体应用里就已经很隐蔽了换成微服务环境只会更难排查。如果你也正在做类似的Spring Boot管理系统我的建议是把重点放在核心业务链路的完整性和数据一致性上而不是堆砌花哨的界面。预约系统的灵魂是“谁能约、怎么约、约完怎么记”前端再好看后台逻辑一团糟上线就是事故。最后分享一个小经验排查预约类业务的并发问题时最好的工具不是日志也不是Debug而是明确的状态流转图。把每一步的输入、输出、异常分支都画清楚哪怕画在纸上代码写起来才不会有模棱两可的地方。我做这个项目时光预约流程的状态流转图就修订了三版每一版都发现一个之前没考虑到的边界情况。好系统真的是改出来的不是一次写出来的。