SSM框架疫苗接种预约系统设计与实现：数据库并发控制与毕业设计实战

1. 毕业设计选题里，疫苗接种预约系统为什么值得做

每年到这个时间点，总有人来问我“毕设做什么题目好”。我的建议一直很明确：优先选业务逻辑完整、能体现框架基本功、演示效果直观的题目。SSM + Java 的社区疫苗接种预约系统，恰好就是这一类里性价比非常高的选择。

先说说这门课题能覆盖的知识面。一个完整的疫苗预约系统，不只是简单的增删改查。用户端要注册、登录、查看疫苗库存、选择接种时间、提交预约、查看预约记录；管理端要维护疫苗信息、审核预约、登记接种结果、做基本的统计报表。光是把这些模块串起来，就已经涉及了 Spring 的依赖注入、SpringMVC 的请求映射与参数绑定、MyBatis 的 SQL 映射与动态查询、前端页面的表单交互、数据库表设计外键关联与状态流转。任何一个“看起来很容易翻车”的环节，都在这个项目里真实存在。用最短的时间把最常见的后端技术栈全练一遍，这件事本身就有价值。

再从毕设评分角度说。社区疫苗接种预约系统的切入点足够小，边界清晰，评审老师一眼就能看懂业务流程；但它内部又包含权限区分（居民/管理员）、预约名额控制（不能超卖）、重复预约拦截、接种状态流转（待接种→已完成→已取消），这些细节都有话可讲，答辩时能有效避免“这个项目做得太浅”的尴尬。相比千篇一律的“学生信息管理系统”“图书管理系统”，疫苗预约带了一点公共服务色彩，在答辩开场白里更容易让老师听出业务场景感。

另外，源码和论文的契合度也重要。SSM 项目属于成熟框架，网上资料多，遇到 bug 容易检索，对基础不够扎实的同学来说，不会因为框架太冷门卡死在环境问题上。而“源码 + 论文”的组合，恰好是多数高校对毕设交付物的标准要求——既要有能跑起来的系统，也要有能说清楚为什么这样做、这样设计的文档。这个题目的论文很好写，因为有真实的数据模型、角色权限、核心算法（预约冲突检测、库存扣减）可以展开，每一章都有具体内容撑腰。

如果你还在犹豫题目，可以先想清楚：你要的不是一个“先进”的题目，而是一个“能在限定时间内完成、答辩时能讲清楚”的题目。疫苗接种预约系统在这两点上都很稳。

2. SSM架构下的系统整体设计：先画清楚业务边界

项目拿到手，不要急着写代码。我见过太多人打开 IDE 就开始建包名，结果写到第三个功能就发现类和类之间的职责互相纠缠，改一个功能连坐一片。第一步应该把系统的边界画清楚，越细越好。

2.1 角色权限与核心业务流程

这类系统最常见的角色划分有三种：普通居民用户、社区接种点管理员、系统管理员。实际毕设中可以把后两者合并成同一套管理员角色，减少部分代码量，但权限逻辑要分开，方便在论文里写“基于角色的访问控制”。用户端能做的事：注册账号、浏览疫苗信息、按日期查看剩余号源、提交预约、取消预约、查看自己的接种记录。管理端能做的事：维护疫苗批次信息、设置每日预约限量、审核用户预约申请、登记实际接种结果、查看统计汇总。

这条流程串起来就是完整闭环：用户登录 → 选择疫苗 → 选择接种日期 → 查看剩余号源 → 提交预约 → 管理员审核（或自动通过）→ 现场核销 → 登记接种结果 → 用户查看记录。设计系统时每个节点的“数据从哪来、到哪去、存到什么表”，都要在动手前想明白。

2.2 为什么用 SSM 而不是 Spring Boot

这个问题答辩必被问，所以提前理清思路。SSM 是 Spring + SpringMVC + MyBatis 的组合，本质上是Spring 管对象、SpringMVC 管 Web 层、MyBatis 管数据库访问的分工体系。Spring Boot 虽然更现代、配置更自动，但它“约定大于配置”的方式把很多底层细节封装掉了，作为教学项目反而不容易体现你对框架原理的理解。SSM 需要你手动写配置文件、管理数据源、配置事务管理器、处理视图解析器，每一步都清清楚楚，正好适合毕设展示基本功。

选型角度有个实用的策略：如果你的学校更看重传统 Java Web 路线，SSM 是稳妥选择；如果老师希望你贴近企业级开发习惯，可以在项目里用 Spring Boot 重写外层，但核心业务代码尽量保持分层清晰，这样两边都能兼顾。不要在这个环节上过度纠结，重要的是把项目中看似“常规”的事务、拦截器、异常处理写到位，这些才是拉开差距的地方。

2.3 后端分层与前端页面规划

标准的三层架构要落实到具体包名：controller、service、mapper（或dao）、entity（或pojo）、common（放统一返回结果、异常处理器、工具类）。这几个包从请求进来到数据返回，职责边界不能乱。Controller 只做参数接收和响应封装，不写 SQL；Service 负责事务边界和业务规则；Mapper 只做持久层映射，复杂 SQL 交给 XML 文件管理。

前端页面不必追求炫酷，用 JSP + Bootstrap 打底是多数毕设的常规路线。JSP 里避免大量 Java 代码，尽量用 JSTL 标签做循环和条件判断；CSS 和 JS 尽量外链，保持页面整洁。真正加分的点是操作反馈，比如预约成功后明确显示订单号、时间、接种地点；预约失败时告诉用户具体原因（库存不足、重复预约、日期不存在），不要只弹一个“系统错误”。

在这个阶段，你需要输出的是一张表：每个功能点对应哪个页面、哪个 Controller 接口、哪个 Service 方法、哪张数据表。这块整理完了，后面写代码基本就是按表填内容。

3. 数据库设计：七张核心表如何撑起预约业务

数据库设计决定了这个项目的上限。评审老师可以不看你的炫酷前端，但一定会打开数据库看表结构。我们按实际业务拆一遍，直接给出可落地的表设计思路。

3.1 核心表清单与职责说明

整个系统我认为六到七张表就足够，别贪多。

第一张是用户表user。字段包含：id、username、password（BCrypt 加密后存储）、phone、id_card（身份证号，用于实名认证）、role（1：普通用户，2：管理员）、create_time。身份证这块要加唯一索引。这个表的使用频率非常高，所有业务的查询都会关联它，所以索引要建好。

第二张是疫苗信息表vaccine。字段包含：id、name（如“乙肝疫苗”“流感疫苗”）、category（疫苗类型）、manufacturer（生产厂商）、dosage（剂次说明）、description、create_time。这张表是管理员维护的静态基础数据。

第三张是库存批次表vaccine_stock。这是系统的核心表之一。每个接种日期的每种疫苗都会有一条库存记录，字段包含：id、vaccine_id、stock_date（接种日期）、total_count（总号源数）、remaining_count（剩余号源数）、version（乐观锁版本号）。为什么单独建库存表而不是在疫苗表里加一个 stock 字段？因为库存不仅跟疫苗有关，还跟日期有关。同一个疫苗不同日期的号源情况完全不同，单独建表才能支持“查某天还剩几个号”这种操作。

第四张是预约单表appointment。字段包含：id、user_id、stock_id（关联库存批次）、appointment_code（预约流水号，唯一）、status（0：待接种，1：已完成，2：已取消）、appointment_time、finish_time、remark。这张表是整个系统的数据枢纽，所有运营统计都围绕它展开。

第五张是接种记录表inoculation_record。字段包含：id、appointment_id、user_id、vaccine_id、dose_number（第几剂）、inoculation_time、operator_id（操作管理员）、remark。这张表可以理解成“用户接种过的疫苗档案”，对应疫苗本功能。

第六张是公告表notice（可选），用于发布接种通知、注意事项等。

加上管理员操作日志表operation_log，记录谁在什么时间对哪个预约单做了什么操作。这张表在答辩时非常加分，因为它展示了系统具备基本的可追溯性。

3.2 预约状态机：一切业务规则的基石

预约单的status字段绝不是随便放几个数字那么简单。我建议在项目里定义清晰的状态常量，并严格限制流转方向：

为什么要把状态机单独拿出来说？因为很多毕设写到最后，状态流转是乱的，用户取消了还能被管理员标记为已完成，后天数据就完全是脏数据。把状态流转规则写死在 Service 层，再在 Controller 层做校验，数据干净了，论文里也有话可写。

3.3 库存扣减的并发设计思路

这是数据库设计中最重要的一个问题。设想一下：某天剩余号源只剩 1 个，两个用户同时点击预约。如果你的 SQL 写的是SELECT remaining_count FROM vaccine_stock WHERE id = ?，判断大于 0 后在 Java 代码里remaining_count - 1，再 UPDATE 回去，那么必然出现超卖——两个人同时读到 1，同时做减法，最后库存变成 -1 已经晚了。

两种主流修法：

第一种是乐观锁。在vaccine_stock表加version字段，UPDATE 时带条件WHERE id = ? AND version = ?，更新成功后version + 1。如果更新影响行数为 0，说明 version 变了，预约失败，提示用户手速慢了。代码逻辑不复杂，但可以有效避免超卖。

第二种是数据库原子操作。直接执行UPDATE vaccine_stock SET remaining_count = remaining_count - 1 WHERE id = ? AND remaining_count > 0，利用数据库行锁保证同一时刻只有一个请求能扣减成功。如果影响行数为 0，说明没库存了。

两种方案可以都写进论文里，并明确说项目里采用的是哪一种，为什么。这种“我不仅实现了功能，还考虑了高并发下的数据一致性”的表述，在答辩时是实打实的加分项。

4. 核心代码实现：预约链路怎么一步步跑通

架构和数据库定了，代码就是填肉。我按照实际开发顺序，挑几个最核心的点详细展开。

4.1 用户登录与角色拦截

登录逻辑用 SpringMVC 的拦截器（Interceptor）实现。用户登录成功后把用户对象放进 Session，写一个LoginInterceptor，在preHandle里判断 Session 是否存在；没有就重定向到登录页。管理员功能的拦截再加一层角色判断，普通用户访问管理员接口直接弹出 403 提示。

这个设计回答了一个常见问题：为什么不是每个 Controller 里都判断一次登录？因为拦截器是横切关注点，对所有请求统一处理，避免重复造轮子。论文里可以把拦截器的执行流程画成文字描述（SpringMVC 的拦截器链执行顺序要能讲清楚）。

4.2 查询某日剩余号源的实现

前端下拉框选了疫苗和日期后，异步请求查询库存。对应的 Service 方法大概是查vaccine_stock表中vaccine_id和stock_date都匹配的记录，返回remaining_count给前端。建议在 SQL 里加上一个条件：stock_date >= CURDATE()，过滤掉历史日期的垃圾数据，避免用户选到过去的日期还能看到号源。

页面显示可以加一点人性化判断：剩余 0 时按钮置灰并显示“已约满”；剩余少于 5 时显示“仅剩 X 剂”的醒目提示（这一步做好，系统会显得非常“完整”，用户体感完全不同）。

4.3 预约接口：事务和并发控制的完整写法

预约接口是核心中的核心。我这里给一份典型的实现思路，伪代码级别，可以照着改编成你自己的 Service。

@Transactional public AppointmentResult createAppointment(AppointmentDTO dto) { // 1. 校验用户是否已有同日同疫苗的预约 int count = appointmentMapper.countByUserAndDate(dto.getUserId(), dto.getVaccineId(), dto.getStockDate()); if (count > 0) { return AppointmentResult.fail("您已预约过该疫苗，请勿重复提交"); } // 2. 乐观锁扣减库存 int rows = stockMapper.decreaseRemaining(dto.getStockId(), 1); if (rows == 0) { return AppointmentResult.fail("该时段号源已约满，请选择其他日期"); } // 3. 生成预约流水号 String code = generateAppointmentCode(dto.getStockId(), dto.getUserId()); // 4. 插入预约记录 Appointment appointment = new Appointment(); appointment.setUserId(dto.getUserId()); appointment.setStockId(dto.getStockId()); appointment.setAppointmentCode(code); appointment.setStatus(0); appointmentMapper.insert(appointment); return AppointmentResult.success(code); }

这个接口有几个细节：@Transactional保证“扣库存 + 插订单”同生共死，中间任何一步报错都整体回滚；“重复预约校验”要放到扣库存之前，否则可能白扣了库存才发现重复；流水号的生成规则要保证唯一，可以用 UUID 截取或用“日期 + 随机数”拼，不要用数据库自增 id 当流水号，因为自增 id 暴露了业务量，且不美观。

4.4 管理员审核与接种核销

管理员操作的核心逻辑是状态机的落地。审核操作：把appointment.status从 0 改为 1（或 2），同时往inoculation_record插入接种记录。这一步也要加事务。操作日志的写入不能省，管理员点了什么按钮、改了哪条记录，都要进operation_log。

核销环节有一个常见 bug：页面加载了用户的预约列表，但管理员连续点击“核销”按钮，可能因为网络延迟导致同一订单被处理两次。解决思路是：核销按钮点击后前端立即禁用，后端在 Service 层再判断一次订单状态，只有“待接种”的订单才能被核销，状态已变就提示“该订单已处理”。

5. 项目开发过程中最容易踩的四个坑

这部分是实战总结。我把带过的学生和自己在开发中常遇到的问题列出来，每一条都踩过或者看别人踩过。

5.1 时区与日期处理不一致

数据库存日期用的是java.util.Date，页面传参用的字符串，JSON 序列化格式不统一，最后出现“页面显示的是昨天但是库里存的是今天”这类诡异 bug。统一方案：数据库字段用DATE或DATETIME，Java 实体类用java.time.LocalDate和LocalDateTime，Spring 配置全局的日期格式化器，前端所有日期传参统一为yyyy-MM-dd格式，在 JSON 配置里设置spring.jackson.date-format。别在代码里各处手动 new SimpleDateFormat，否则早晚格式不一致。

5.2 事务失效让你怀疑人生

@Transactional标在 Service 方法上，但事务没生效，数据出现半截更新。最常见的原因是方法内部自调用：同一个类里的方法 A 调方法 B，B 上有@Transactional，但 A 没有。Spring 的事务是通过 AOP 代理实现的，自调用走的是 this.method()，代理对象不参与，事务直接失效。解决办法：事务要写在入口方法上，或者注入自身代理对象，或者把事务方法放到另一个 Service 里。排查这类问题最有用的手段是打开 MyBatis SQL 日志，看 UPDATE 语句是不是真的在一个事务里执行。

5.3 数据库字段与实体类映射对不上

MyBatis 默认开启驼峰映射后，remaining_count这种带下划线的字段可以正确映射到remainingCount。但如果你遇到字段老是 null，去查两个地方：mybatis-config.xml里有没有开启map-underscore-to-camel-case，以及 SQL 别名是否写对。另外建议所有表字段都用下划线风格，实体类统一驼峰，避免混搭造成的无谓排查。

5.4 文件资源路径混乱，部署就崩

SSM 项目用 Maven 构建时，很多人会把配置文件直接放在src/main/java包里，导致打包后配置文件丢失，本地跑得好好的，一换环境就 404。正确做法：applicationContext.xml、spring-mvc.xml、mybatis-config.xml、db.properties统一放在src/main/resources下，用classpath:方式引入。部署时用外置 Tomcat 运行 war 包，确认WEB-INF/classes下能看到配置文件。

6. 论文写作与答辩演示的实操建议

源码写完了，论文不能随便糊弄。毕设论文的套路是固定的，但要把每个章节写出真实感。

6.1 论文章节架构怎么排

第一部分写绪论，重点放在“为什么要做疫苗接种预约”的背景分析和国内外现状，不要花大篇幅抄框架介绍，老师不爱看。系统需求分析要写清楚功能性需求、非功能性需求（响应时间、安全性、并发量预估）和可行性分析。系统设计章节把总体架构、模块设计、数据库设计说透，ER 图和数据字典是这一章的灵魂，画清楚 7 张表之间的关系，论文的基本盘就稳了。系统实现章节不用罗列全部代码，挑登录模块、预约模块、库存扣减、核销登记这几个有技术含量的环节放核心代码片段和解释。最后写测试。

6.2 演示 Demo 的准备工作

答辩演示是有技巧的。提前准备一组演示数据非常关键：两个测试账号（一个用户、一个管理员）、未来三天的库存号源、几条预约记录、一条已完成记录、一条已取消记录。演示时按业务闭环走：用户登录 → 查疫苗 → 预约成功 → 管理端看到新预约 → 核销 → 用户端看到接种记录。绝不要现场注册新用户从头走一遍，很容易卡在验证码或邮箱激活这种环境问题上。把最容易出错的环节提前跑顺，把操作步骤写在纸条上，演示的时候按流程点，不要临场发挥。

6.3 答辩前期准备与高频问题

准备好回答这几类固定问题：为什么选 SSM 框架；数据库为什么这样设计；库存扣减怎么防超卖；登录状态怎么管理的；这个系统如果上线，哪些地方还需要改进。每个问题准备两三句话的回答，核心的代码片段要能默写出思路。一句话提醒：论文里的每个图、每个表，你都要能随时讲清楚它是干什么用的。如果老师问到一个你没画出来的模块，你说“这个模块为了方便演示省略了”，比支支吾吾半天说不出话要强得多。

7. 项目演示效果的关键处理：把普通功能做出“完整产品感”

很多人忽略了这一点：同样的功能，呈现方式不同，答辩效果天差地别。疫苗接种预约系统如果只是表格堆数据，三分钟就能演示完，老师也记不住任何亮点。但如果你在细节上多花一点心思，整个项目的“完成度”会立刻不同——这正是拿高分和及格分的分水岭。

第一是前端页面的反馈细节。提交预约成功之后，不要停留在原页面，直接跳转到一个预约成功页，展示预约流水号、疫苗名称、接种日期、接种点地址，再加一行“请携带身份证和预约码按时前往”的提示。取消预约时加上二次确认弹窗（用原生 confirm 就行），防止误触。查询列表里如果当天有即将到期的预约（比如明天就要接种），在列表顶部用高亮提示。这些改动每个工作量都不大，但能把“一个管理系统”变成“一个像样的产品”。

第二是首页仪表盘。管理员登录后不要直接进列表页，做一个简单的数据概览：今日预约人数、待核销数量、疫苗总库存量、近七日预约趋势折线图。图表不用真的上 ECharts，用简单的 CSS 图块和表格也能达到效果，但一定要有数据可视化意识。这个页面在答辩演示时放在第二位展示（第一位必然是登录和角色进入），会瞬间拉升老师对项目的整体印象。

第三是空数据状态的文案处理。列表为空时不要只显示一个空白表格，写一句“暂无预约记录”，配一个返回首页的链接；查询结果为空时提示“没有找到符合条件的记录，请调整筛选条件”。这种细节代码量很少，但体现的是完整产品的思维，答辩时随口提一句“我注意到空状态处理让系统体验更完整”，就能变成加分项。

8. 部署发布与环境迁移的注意事项

毕设项目答辩时一般要现场部署，很多人在这一步翻车。提前把这个流程走顺，能省掉答辩前一晚的崩溃。

环境统一化是关键：JDK 不要用太新的版本，推荐 1.8，兼容性最好，SSM 框架对旧版本 JDK 的支持非常成熟；Tomcat 用 8.5 或 9.0；MySQL 用 5.7 左右即可；Maven 用 3.6 以上的稳定版。数据库初始化脚本要单独放在一个sql目录里，包含建库语句、建表语句、初始数据语句，导师或评审要还原环境时执行一个脚本就能跑起来。

数据库连接配置放db.properties，账号密码根据自己的环境改，但提交源码时记得把注释写好——哪些地方需要改、改成什么，都标清楚。项目部署有两种方式：一种是 IDE 里直接配置 Tomcat 运行（适合自己开发时调试），另一种是把项目打成 war 包丢进 Tomcat 的webapps目录（适合答辩现场演示）。

这里有一个非常容易踩的坑：运行环境的 MySQL 字符集。建库时明确指定utf8mb4，否则插入生僻字或特殊符号会报错。字符集问题在本地可能不会暴露，换一台电脑就出问题，务必在建库脚本里固定写清楚。

还有，答辩前的最后一轮自测，务必走一遍完整闭环：从管理员新建疫苗批次、设置每日库存，到用户注册、登录、预约、取消、再预约、到管理员核销、查看接种记录、查看日志、看统计面板。整套流程走顺了，你的心里就有底了。

把 SSM 和 Java 框架吃透，把数据库设计想清楚，把核心的并发控制代码写出来，再把论文和演示流程准备到位，这个项目就不只是一套可以提交的毕设作业，而是你能拿得出手向别人证明“我具备独立开发一个完整业务系统”能力的作品。

最后再分享一个小技巧：如果时间允许，可以在系统里给管理员加一个“库存预警”功能——当某疫苗第二天号源剩余数低于总数 20% 时，在首页仪表盘中显示“疫苗库存紧张”的红色标签。这个功能实现非常简单，却能让你的系统在评委眼中立刻多出一个真实业务系统的维度。我在实际带项目时反复验证过，这样的小细节往往比多写一个 CRUD 模块更让人印象深刻。