如果你今年也在为计算机毕业设计发愁我建议认真看看这个Java毕设方向基于SpringBoot的九价宫颈癌疫苗线上摇号与排号系统。这个项目本质上是一个JavaWeb实现的成人疫苗智慧接种服务平台用户端负责疫苗公示、摇号申请、排号查询、预约接种管理端负责批次管理、摇号执行、放号审核和数据统计。我做完这个项目最大的感受是它不像很多毕设题目那样“看起来是系统做起来是CRUD”而是把Java后端开发里最容易出彩的几个点全占齐了公平性算法、排队号段管理、高并发库存控制、定时任务自动化。这篇就把我的整套设计思路、表结构、核心代码和踩坑记录完整分享出来不管你是准备答辩还是想从里面摘几个功能写进简历都能用得上。1. 项目到底在做什么先看清业务再谈代码1.1 为什么毕设选“疫苗摇号排号”这个方向九价HPV疫苗这几年的需求大家有目共睹供给一直处于“放一批约空一批”的状态。线下排队容易聚集、黄牛抢号破坏公平、接种点电话通知效率低这些真实痛点收集起来就是一个非常典型的业务系统题目。这个题目好在哪里从毕设角度看它有明确的业务规则摇号要保证随机公平排号要保证先到先得预约要防止重复和超卖接种完成后要生成记录。这些规则不是靠堆CRUD就能糊弄过去的你需要认真设计状态流转、并发控制、定时任务每一个环节都能在论文里写出“为什么这么做”的深度。从面试角度看疫苗预约涉及低频高并发流量、库存扣减、防重提交这些都是Java后端岗位最常考察的实际场景比单纯的学生管理系统有说服力得多。我最初也犹豫过要不要换成普通的“医院挂号系统”后来对比发现挂号系统本质上只有“排号预约”两个环节疫苗预约系统多了“摇号”这个随机分配过程业务层次更丰富论文目录更好展开。答辩老师问起来你能讲清楚“摇号和排号在什么场景下分别使用”就已经赢了一半。1.2 系统角色与核心业务流角色拆解要清晰这直接决定后面的权限设计和页面规划。这个系统我分了三个角色普通用户注册登录、实名认证、查看疫苗批次、提交摇号申请、提交排号申请、查看中签结果、预约接种时间、查看接种记录。接种点管理员维护疫苗批次信息、配置每次放号数量、发起摇号、管理排号队列、审核预约、登记接种结果。系统管理员管理用户账号、管理接种点、发布公告、查看全平台数据统计。核心业务流是一条完整链路用户实名认证通过后在疫苗公示页选择自己要参与的批次如果该批次采用“摇号模式”系统在截止时间后统一开奖中签用户获得一个预约资格如果采用“排号模式”系统按申请顺序生成队列号排到号后用户必须在规定时间内完成预约预约成功后在指定时间到接种点管理员扫码或核对身份后登记接种完成。状态流转是这类系统的灵魂。我在代码里用一个独立的枚举类管理所有状态避免魔法数字散落在业务逻辑里。申请表的状态包括“待摇号”“已中签”“未中签”“已取消”预约单的状态包括“待预约”“已预约”“已过期”“已完成”每个状态之间的迁移都对应一个Service方法这个方法里做校验、做更新、做记录保证状态不会乱跳。1.3 什么是“摇号”和“排号”并存的设计老实说我一开始想过只做“摇号”一个模式因为大部分疫苗预约系统都只做摇号。但后来参考了几个真实平台的规则发现摇号适合“供给严重不足、需求远超库存”的场景比如九价HPV疫苗每次只有几十针但有上万人报名排号适合“供给相对稳定、按时间顺序推进”的场景比如四价疫苗和部分成人疫苗。两种模式并存为什么合理因为它让系统具备普适性。管理员新建一个批次时可以选择分配模式摇号模式走随机抽取逻辑排号模式走队列递增逻辑底层共用名额扣减和预约资格校验代码复用率很高。答辩时这就是一个亮点“系统不只解决单一场景而是抽象了两种公平分配策略。”我建议你也按这个思路设计既展示了业务分析能力又展示了代码抽象能力。2. 技术选型这些东西不是随便选的2.1 SpringBoot为什么是JavaWeb毕设的“标准答案”咱们平时说的JavaWeb早期是ServletJSP的天下后来演化出SSHStrutsSpringHibernate、SSMSpringSpringMVCMyBatis再到现在的SpringBoot。SpringBoot最核心的改变是“约定大于配置”它把Tomcat内嵌进启动器你不需要单独部署war包到外部容器一个java -jar命令就能跑起来。对毕设来说SpringBoot有三个实打实的好处。第一配置量大幅减少不再需要写一堆XML文件适合短期开发第二Spring生态无缝集成MyBatis、Spring Security、Spring Task这些组件全是“引依赖写配置”就能用第三简历上写“熟练使用SpringBoot”比写“了解Servlet”有竞争力得多。我用的就是SpringBoot 2.7.x搭配JDK 8这个组合在毕业设计语境下最稳妥网上资料多遇到问题搜索时基本都能找到答案。2.2 周边组件选型的权衡数据访问层我选的是MyBatis-Plus不是原版MyBatis。原因很简单MyBatis-Plus内置了通用的增删改查方法像用户表、通知记录表这种基础操作无需手写SQL开发效率高出一截。遇到复杂查询时又保留了XML自定义SQL的能力摇号记录的分页统计、疫苗批次的关联查询都能写。还有一个加分项是它的分页插件只需配置一个拦截器就能直接调用分页查询省去手写LIMIT的麻烦。权限认证这块是很多人的纠结所在。我用了JWT拦截器的方式没有上Spring Security因为Spring Security的学习成本对毕设来说偏重配置不当反而容易出问题。JWT无状态认证更直观用户登录后服务端返回一个带过期时间的token前端每次请求带上我在拦截器里统一解析、校验、放行。管理端和用户端用两个拦截路径区分/api/user/**需要用户身份/api/admin/**需要管理员身份逻辑清楚还能写进论文“安全模块设计”一节。前端我选择了Thymeleaf服务端渲染而不是前后端分离。这里不是我不会Vue而是综合考虑了查重和论文工作量Thymeleaf直接把数据渲染到HTML页面项目结构精简不需要维护两套工程加上少量JavaScript和Ajax处理异步交互足以实现疫苗公示、摇号结果弹出、预约时间选择这些功能。如果你时间充裕后期完全可以拆成Vue3SpringBoot前后端分离版本这个我最后一节会讲。2.3 版本搭配与开发环境实操建议如果你照抄我的环境请记住这份组合JDK 8、Maven 3.6、SpringBoot 2.7.x、MyBatis-Plus 3.5.x、MySQL 5.7或8.0、IDEA 2023系。别盲目上SpringBoot 3.x它要求JDK 17虽然新版本性能更好但很多旧教程和第三方依赖在3.x环境下会报兼容问题毕设阶段没时间折腾这些。数据库工具我用的Navicat日常建表、导数据、写测试SQL都很顺手。连接池选了Druid它自带监控页面能实时看到SQL执行次数和耗时调试慢查询很有用。初始化工程的流程是这样的在IDEA里用Spring Initializr创建项目勾选Web、MySQL Driver、MyBatis相关依赖然后手动引入MyBatis-Plus和JWT的jar包application.yml里配置数据源、MyBatis-Plus的日志输出和分页插件启动后能访问localhost:8080就算基础环境通了。提示application.yml里的数据源密码、JWT密钥等敏感配置毕设阶段也建议用${ENV_VAR}方式读取或单独编写配置文件既显得专业也避免代码上传后泄露。3. 数据库设计与核心表拆解3.1 八张核心表一个都不能少这个系统的表并不算多但每张表的字段设计都要围绕业务状态流转来展开。我最终设计出以下八张核心表用户表、疫苗批次表、摇号申请表、摇号记录表、排号表、预约表、接种记录表、通知记录表。有人问疫苗接种记录能不能和预约表合并我的建议是分开因为一条预约记录只能对应一次接种但一次接种可能涉及第二针、第三针的后续跟踪独立成表更清晰。每张表的重点字段我列出来给你参考表名关键字段设计说明t_userid、phone、id_card、real_name、status手机号唯一索引实名认证信息冗余存储t_vaccine_batchid、vaccine_name、total_count、remaining_count、mode、status、start_time、end_timemode区分摇号/排号remaining_count用于库存扣减t_lottery_applyid、user_id、batch_id、apply_time、statususer_idbatch_id建立唯一索引防重复申请t_lottery_recordid、batch_id、user_id、result、create_time每轮摇号的结果流水放下中签用户也算一条t_queue_numberid、user_id、batch_id、queue_no、status、expire_timequeue_no是核心体现排号顺序t_appointmentid、user_id、batch_id、appointment_time、status关联批次和用户体现预约资格是否可用t_vaccination_recordid、appointment_id、user_id、vaccinate_time、operator管理员登记接种完成时写入t_notificationid、user_id、title、content、send_type、is_read站内信通知并记录阅读状态额外加一张t_vaccine_station接种点表也是合理的如果论文要求“平台”的概念接种点作为独立管理维度会让系统更完整。我当时把接种点信息直接冗余到了批次表里后来答辩时老师建议拆出来这个看你自己时间安排。3.2 状态字段与唯一索引的设计哲学状态字段我统一用Integer类型1代表一个含义2代表另一个含义数据库层面只存数字Java代码层面用枚举类做映射。为什么不直接用字符串“WAIT_LOTTERY”因为数字做索引更高效且枚举类可以提供getDesc()方法返回中文描述前端展示、列表筛选都很方便。唯一需要小心的是枚举的调整成本所以设计阶段要把状态机画完整再动手写代码。唯一索引是防重复的“最后一道防线”。前端按钮可以置灰Service层可以判断但这些都挡不住高并发下两条请求同时穿过校验逻辑最终靠的一定是数据库约束。我专门为t_lottery_apply表建了uk_user_batch(user_id, batch_id)唯一索引为t_queue_number表也建了同样的唯一索引只要用户对同一批次重复申请数据库直接报Duplicate entry异常Service层捕获后转为友好的提示这在论文里写为“多级幂等设计”。3.3 数据库层面的ER关系与设计原则这个系统遵循的是“用户—申请—批次—预约—记录”的主线ER关系比较简单用户对批次可以发起一条申请一个批次可以收到多条申请中签或排到号后生成预约单一次预约对应一次接种记录。我建表时坚持三个原则主键用bigint自增不用UUID因为UUID的随机性会导致InnoDB索引页频繁分裂所有时间字段用datetime不用timestamp避免2038年问题凡涉及金额、数量的字段用int存最小单位或直接用int计数不用浮点数。设计数据库时有一个容易忽略的点是“冗余字段的适度使用”。比如t_lottery_apply表里冗余了real_name和phone字段虽然违反了严格的三范式但我后面摇号结果列表要展示姓名和手机号时一次查询就能搞定不需要联表两张表。对于毕设系统适度冗余换查询效率是划算的这个取舍答辩时主动讲出来老师会觉得你有工程经验。4. 核心业务逻辑实现这才是答辩和面试的亮点4.1 公平摇号两种随机算法怎么选摇号的本质是在所有有效申请中随机抽取N个中签者。最简单的做法是循环生成随机数但这存在概率分布不均的问题而且代码写出来不够有章法。我推荐使用Fisher-Yates洗牌算法把所有申请人的ID放入一个List中从后往前遍历每次将当前位置元素与随机位置元素交换洗牌完成后取前N个作为中签者。核心代码大概是这样的public ListLong drawWinners(ListLong applicantIds, int winnerCount) { ListLong list new ArrayList(applicantIds); Random random new Random(); for (int i list.size() - 1; i 0; i--) { int j random.nextInt(i 1); Collections.swap(list, i, j); } return list.subList(0, Math.min(winnerCount, list.size())); }为什么用洗牌而不是直接random.nextInt(size)抽N次因为洗牌算法保证每个位置被选中的概率都是1/n且一次洗牌后直接取前缀逻辑清晰、效率高时间复杂度O(n)。你还能顺手记录下未中签的用户为后续“候补名单”功能预留接口。实际摇号还有一层业务逻辑摇号前必须校验批次是否为摇号模式、是否已截止、剩余名额是否大于0然后在一个事务里完成三件事——更新批次状态为“已开奖”、批量插入摇号记录、为每个中签用户生成预约资格。注意这三步必须是事务否则可能出现“中签记录写了预约资格没生成”的脏数据。4.2 排号队列先到先得的落地实现排号模式比摇号简单但有一个关键设计要处理好排号序号queue_no如何生成才能既保证公平又能撑住并发。我的方案是在t_queue_number表里预先生成一段连续的queue_no比如100个号存入一个号段表用户申请时通过数据库自增主键返回自增ID作为队号。更简单直接的方式是查询当前批次最大queue_no然后加1但这个在高并发下要加SELECT ... FOR UPDATE锁否则两个用户可能拿到同一个号。我更推荐的方案是用MySQL的AUTO_INCREMENT做天然原子递增。建一个批次号段表t_queue_segment(batch_id, current_no, end_no)用户申请排号时执行UPDATE t_queue_segment SET current_no current_no 1 WHERE batch_id ?这条UPDATE自带行锁天然防止并发拿到重复号然后读取更新后的current_no作为用户的queue_no。这个方法实测下来非常稳而且逻辑简单一条SQL就解决了。4.3 防超卖三种手段必须叠加“超卖”是疫苗预约系统的核心风险点。想象一个批次只剩最后1个名额1000个人同时提交预约如果代码是“先查剩余数量大于0就减1”那么这1000个请求都能查到剩余1然后全部执行减1最终预约出去1000个名额这就是典型的超卖。我在系统里叠了三层防护。第一层是数据库层面乐观锁在t_vaccine_batch表加version字段扣减库存时执行UPDATE t_vaccine_batch SET remaining_count remaining_count - 1, version version 1 WHERE id ? AND remaining_count 0 AND version ?这条SQL的意思是“只有剩余数量大于0且版本号匹配时才扣减同时版本号加1”。如果affected rows为0说明库存已被抢完业务层直接返回“名额已满”。这是防超卖最核心的一招简单高效不需要额外引入Redis就能扛住毕设级别的并发。第二层是预约资格的唯一约束。中签用户和排到号的用户会生成一条预约资格记录我在t_appointment表的user_id batch_id上加了唯一索引即使用户重复点击预约按钮数据库也会拒绝第二条。第三层是事务边界。扣减库存和生成预约记录放在同一个Transactional方法中任何一步失败都整体回滚不会出现“库存减了但预约资格没生成”的中间态。4.4 定时任务中签过期释放与批次自动放号疫苗预约有很强的时效性中签后如果24小时内不预约资格就应该作废并释放给候补用户批次到了开放时间系统应该自动把状态从“未开始”改为“摇号中”。这些操作不可能靠人工盯着后台点按钮必须用定时任务。SpringBoot提供了Scheduled注解配置一个Cron表达式就能定时执行方法。我写了两个调度任务一个是每30分钟扫描一次t_appointment表把所有创建时间超过24小时且状态为“待预约”的记录更新为“已过期”同时释放对应批次的remaining_count另一个是每小时扫描一次t_vaccine_batch表把到达start_time的批次状态自动更新为“申请中”。这里有个新手容易踩的坑Scheduled默认是单线程执行的如果多个任务执行时间过长会互相阻塞。我在启动类上加了EnableScheduling并为长时间任务设置了Async异步执行避免阻塞主线程。如果你后面把项目部署到多台服务器上同一个定时任务会在多台机器上重复执行那时需要引入Redis分布式锁做互斥这是进阶方向答辩时能说出来就很加分。4.5 消息通知站内信、短信和邮件怎么选中签、排到号、预约成功这些关键节点都需要通知用户。短信和邮件都需要第三方服务要么花钱要么需要申请模板对于毕设来说不划算站内信是纯数据库操作不依赖外部服务作为主要的通知方式最实际。我的通知模块是这样设计的定义NotificationService接口提供一个send(Long userId, String title, String content)方法方法内插入t_notification表用户端页面通过Ajax轮询未读消息数量有新消息时弹窗提醒。同时我预留了短信和邮件的接口实现类论文里写“采用策略模式便于后续扩展短信网关”但实际不接入既保证了架构的完整性又控制了成本。5. JavaWeb完整项目长什么样目录、接口与页面5.1 项目目录结构实操SpringBoot项目搞分层不是为了好看而是为了让代码职责清晰、答辩时好讲。我实际使用的目录结构是这样的src/main/java/com/example/vaccine ├── controller // 控制层接收请求、参数校验、调用service │ ├── user // 用户端接口 │ └── admin // 管理端接口 ├── service // 业务逻辑层接口实现类分离 │ ├── impl ├── mapper // MyBatis-Plus数据访问层 ├── entity // 数据库实体类 ├── dto // 请求/响应对象避免直接返回实体暴露多余字段 ├── config // 配置类如拦截器、分页插件、CORS ├── common // 公共类如统一返回Result、枚举类、常量类 ├── utils // 工具类如JWT工具、时间格式化工具 └── task // 定时任务类每个包的作用我都在论文里写了一小段这是白拿的深度。特别说一下dto包很多同学直接把后端实体Entity返回给前端导致用户密码、身份证号等敏感字段暴露我短期做的优化是定义UserVO只返回必要的字段再用BeanUtils拷贝属性这种细节也是加分项。5.2 用户端和管理端页面清单页面规划可以直接对照功能清单来做我先列一份最小可用页面清单用户端页面登录注册页、疫苗公示列表页、疫苗批次详情页、摇号申请页、排号申请页、我的申请列表页、中签结果页、预约时间选择页、我的预约页、接种记录页。管理端页面管理员登录页、疫苗批次管理页、申请人列表审核页、摇号操作页、排号管理页、预约管理页、接种登记页、数据统计页。疫苗公示列表页我建议做成一个类似电商列表的卡片式布局每张卡片显示疫苗名称、剩余数量、接种点、申请起止时间、当前模式摇号/排号用户点击“立即申请”后弹出确认框。如果剩余数量为0卡片上必须置灰显示“已约满”这个状态由后端实时返回不要在前端自己写死。5.3 接口设计风格与统一返回格式接口风格我统一用RESTful风格用户端接口以/api/user/**开头管理端接口以/api/admin/**开头。举几个典型接口POST /api/user/lottery/apply提交摇号申请、GET /api/user/lottery/result?batchId1查询中签结果、POST /api/admin/batch/create新建疫苗批次、POST /api/admin/lottery/execute执行摇号。所有接口的返回格式统一为Result对象包含三个字段code200成功500失败、message提示信息、data数据负载。这个设计非常实用前端只需要一个通用拦截函数处理响应遇到code500时弹出message不用每个接口单独判断。接口文档我用Swagger生成配上ApiOperation注解论文里截图一张接口清单答辩老师看到会觉得项目完成度很高。6. 实战踩坑与排查记录这些问题网上基本搜不全6.1 高并发下同一用户重复申请同一批次这是我在联调阶段遇到的第一个棘手的并发问题。我用JMeter模拟200个并发请求全部来自同一个用户点击摇号申请接口结果数据库里出现了多条申请记录。原因是我在Service层先做了“查询是否已申请”的判断再执行插入这两步之间存在时间窗口200个请求全部穿过了查询判断同时执行了插入。排查思路很直接第一层检查前端按钮在点击后已经置灰但这只能挡住正常人操作拦不住脚本第二层检查后端Service加synchronized代码块也不好使因为服务器多线程下synchronized锁的是对象实例多个并发请求可能落在不同实例上最终解决问题的是数据库唯一索引。加了uk_user_batch之后重复插入直接抛异常我在Service层捕获DuplicateKeyException并返回“您已申请过该批次”这个方案彻底封死了重复申请。现在把这个经验写出来就是提醒你防重复这种问题别依赖应用层判断数据库唯一索引才是王道。6.2 定时任务执行两次与事务注解失效定时任务上线后发现一个诡异现象每天早上的批次自动放号任务执行了两次生成的两批记录一模一样。排查后发现我没有在启动类加EnableScheduling而是无意中在配置类上加了导致Spring容器启动了两个调度注册流程。解决办法是只保留一个EnableScheduling且确保定时任务方法所在的类被Spring正常扫描不要在类上同时加Component和EnableScheduling。还有一个事务失效问题我写过一段代码saveAppointment()方法里调用了同类中的deductStock()方法但deductStock()上的Transactional没有生效。原因很经典——同类内部调用不会经过Spring代理事务注解被绕过。解决方式有两种把两个方法放到不同类中或者在内部注入自身代理Autowired后调用更推荐的是把库存扣减和预约生成合并成一个独立的事务方法避免跨方法事务边界。6.3 中签名单扩大摇号事务的“竞态条件”有次并发测试摇号接口时我设置了批次名额50个、有效申请人数80人本应只中签50人结果出现51条中签记录。仔细排查后发现问题出在“摇号执行”和“名额扣减”之间没有加锁。并发场景下两个摇号请求同时读到剩余名额为50第一个请求抽了50人并扣减库存第二个请求又读到未更新的剩余名额为50再次抽了50人导致超出。解决办法是在摇号执行方法上加了Transactional并且用SELECT ... FOR UPDATE锁定批次行确保同一批次同一时刻只有一个摇号任务在执行。这本质上和防超卖是一个思路但业务场景不同一个是库存扣减的并发问题一个是整体流程的并发问题两个地方都要处理。我后来还把中签名单插入和剩余名额扣减的先后顺序固定为“先扣减、后写记录”如果记录写入失败事务回滚名额也会回滚没有中间状态。6.4 前端时间显示一串英文和“T”字符前后端联调时发现疫苗批次列表页的截止时间显示成2025-05-01T08:00:00这样的格式原因很简单默认的JSON序列化把LocalDateTime输出成了ISO格式而前端没有对应的解析库则直接原样展示用户体验很差。而且前端拿到的时间是UTC时间在中国使用时还会差8个小时。解决办法最直接的是在application.yml配置Jackson的全局时间格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8实体类里的时间字段如果用了LocalDateTime还需要注意分页插件的依赖可能会和Jackson产生参数序列化上的冲突遇到的话单独在字段上加JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8)。这个问题看着是小问题但答辩演示的时候如果时间格式不对给老师的印象分直接下降一个档。6.5 管理员后台列表加载巨慢没有用分页插件开发初期管理端的“申请人列表”接口直接查询全部数据返回数据量到了几千条时页面响应已经明显变慢。后来我把所有列表接口都切换为MyBatis-Plus的分页查询前端用PageHelper风格的参数pageNum和pageSize后端返回total总条数和records当前页数据。分页插件是MyBatis-Plus的一个内置配置几行代码就接入启动时自动拦截SQL拼上LIMIT对应用完全无感。这里还想多说一句分页之后传给前端的total不能拿查询出来的记录数而是要通过分页插件的Page对象获取真实的getTotal()。很多同学在这一步图省事直接返回list.size()一旦分页total永远等于pageSize列表底部的分页器就出bug了。这些都是实操细节测试的时候要专门点一遍。7. 答辩准备与后续扩展方向7.1 答辩高频问题清单与答题思路答辩老师最常问的问题其实就集中在几个方向上我把自己积累的答题思路整理成了清单。为什么选择SpringBoot而不是传统SSM答SpringBoot简化了配置和部署内嵌容器适合快速构建微服务同时它本身基于Spring生态底层原理与SSM一脉相承。摇号如何保证公平性答使用洗牌算法保证概率均等每次摇号基于随机数和全量申请人列表中签结果不依赖申请先后。排号和摇号的本质区别是什么答摇号是随机抽签排号是先到先得摇号解决供给严重不足的公平问题排号适合数量稳定场景下的顺序分配。如何防止用户重复预约答前端按钮置灰加后端唯一索引双重保证最终靠数据库约束兜底。如何应对高并发答缩减资源竞争使用数据库乐观锁和唯一索引控制并发必要时引入缓存和队列削峰。把这五个问题吃透答辩基本就稳了。如果老师深挖“洗牌算法的时间复杂度是O(n)”这种基础问题也照着刷一遍就行。7.2 从“能做”到“优秀”三个低成本升级方向毕设交完不等于项目结束如果想把这段经历转化成简历上的亮点我推荐三个由易到难的升级方向。第一引入Redis缓存热数据。疫苗公示列表和批次详情是高频访问的“冷热分离”场景把热点批次缓存到Redis设置过期时间能显著降低数据库压力。这个方案代码改造量小但“缓存一致性”“缓存穿透”这些知识点够你写很长一段技术总结。第二将系统拆成前后端分离版本。把Thymeleaf页面换成Vue3Element Plus接口改用JSON交互部署时前端用Nginx后端用SpringBoot打jar这样你的简历上可以写“熟悉前后端分离开发与Nginx部署”竞争力完全不一样。第三引入RabbitMQ做异步通知削峰。高并发摇号时中签通知邮件和短信可以丢进消息队列由消费者异步发送避免瞬时压力阻塞主流程。这一项能体现出消息中间件的能力面试聊到项目时非常加分。7.3 如果你也在做类似毕设最后几点建议整个项目做下来我最想强调的一件事是先把状态机和业务流程图画清楚再动手写代码。这个项目过程中我光状态流转的图就改了三次每次改动都牵动一堆SQL和接口逻辑如果一开始想清楚至少能省一周的时间。另外代码提交前一定要跑一遍核心测试用例尤其是摇号并发、重复预约、定时任务释放名额这三个场景。我曾经因为没测“中签过期自动取消”答辩演示时定时任务没有按时触发现场直接卡了壳后来才发现是Cron表达式写错时区。这种低级错误完全可以通过提前整理一份测试清单来避免。希望我这篇完整的实战拆解能帮你把这个毕设题目做出真正让人眼前一亮的水平。
