很多管理系统做完以后只剩下一组 CRUD 页面，但疫苗接种场景真正的难点，是把“疫苗信息—用户预约—医生接种—接种记录—异常处理—库存变化”串成一条可追踪的业务链。

本文以一个基于 Spring Boot + Vue.js 的新生儿疫苗接种管理系统为例，从业务功能、技术架构、数据库设计、关键接口和测试过程五个角度进行拆解。相比论文原稿，本文删去了大段通用技术介绍，重点保留可以直接复用的项目设计思路。

说明 本文只讨论软件系统设计与实现，不提供疫苗接种、疾病诊断、用药或其他医疗建议。真实医疗系统还必须满足隐私保护、数据合规、审计追踪及行业监管要求。

1. 项目要解决什么问题？

传统的纸质登记或分散表格管理，容易出现信息重复、查询缓慢、预约冲突、库存变化无法及时同步等问题。系统的目标不是简单地把纸面表格搬到网页，而是建立统一的数据入口和业务流程，让不同角色在同一套数据上协同工作。

• 对接种人/监护人：查询疫苗信息、提交预约、查看预约与接种记录。
• 对医生：查看预约信息，记录接种结果及异常情况。
• 对管理员：维护用户、医生、疫苗、供应商、库存、财务和站点公告等数据。
• 对系统运维：通过统一数据库保存关键业务数据，便于后续查询、统计和追踪。

图 1　系统登录页：不同角色从统一入口进入系统

2. 技术栈与系统架构

系统采用 B/S 架构，客户端通过浏览器访问。前端负责页面交互与状态管理，后端提供业务接口，MySQL 保存结构化数据。论文中的技术选型如下。

层次	主要技术	作用
前端	Vue.js、Vue-Router、Vuex、Element UI、Ajax	实现单页应用、路由跳转、全局状态管理、组件化页面与前后端通信。
后端	Spring Boot、MyBatis	承载登录、用户、疫苗、预约、库存和接种记录等业务接口。
数据层	MySQL、Redis	MySQL 保存核心业务数据；Redis 可用于缓存或会话类数据。
架构	B/S 前后端分离	浏览器即可使用，便于部署、维护和后续功能扩展。

图 2　管理员首页：集中管理站点、用户、疫苗、预约与库存数据

3. 角色与功能模块

系统包含管理员、接种人/监护人和医生等角色。角色划分的核心价值是把“查看、提交、审核、记录、维护”这些操作分离，避免所有用户拥有同样的权限。

角色	核心操作	对应模块
管理员	维护基础数据、审核与统计	用户管理、医生管理、疫苗信息、可预约疫苗、供应商、入库、出库、财务、异常信息、公告栏等。
接种人/监护人	注册登录、查询与预约	疫苗浏览、预约接种、预约记录、接种记录、异常信息查看、评价。
医生	处理预约并形成记录	查看预约信息、确认接种、填写接种记录和异常情况。

管理员端的模块数量较多，但可以按业务域重新归类：基础档案、预约接种、库存供应、异常与评价、运营与财务。这样比按页面逐个堆功能更便于后续维护。

4. 核心业务闭环

一个完整的预约接种流程可以拆成以下七步：

1. 用户注册并登录，系统校验账号、审核状态和可用状态。
2. 用户浏览疫苗信息与可预约疫苗，确认疫苗编号、名称、价格、剂次和适合年龄等信息。
3. 用户填写儿童姓名、年龄、健康状态、接种医生和接种时间，提交预约。
4. 系统生成订单编号和预约记录，管理员或医生可以在后台查询。
5. 接种完成后写入接种记录；发生异常时，单独保存异常信息，避免与普通记录混在一起。
6. 库存模块同步入库与出库数据，管理员可以追踪疫苗来源和使用情况。
7. 用户查看历史记录并提交评价，系统形成相对完整的业务闭环。

图 3　预约接种表单：采集儿童、疫苗、医生和接种时间等关键字段

5. 数据库设计：围绕业务单据建模

论文中的数据库表覆盖预约、接种、疫苗、库存、医生、接种人、供应商、财务和评价等业务。对于此类系统，建议围绕“主数据 + 业务单据 + 过程记录”三类数据进行建模。

• 主数据：vaccine_information、doctor、vaccinated_by、supplier_information。
• 业务单据：vaccine_reservation、appointment_vaccination、appointment_record。
• 过程记录：vaccination_record、vaccination_exception_information、warehousing_management、ex_warehouse_management、evaluate、financial_management。

以 appointment_record 为例，核心字段包括订单编号、儿童编号、儿童姓名、预约时间、疫苗名称、医生编号、医生姓名、疫苗编号和用户编号。这样的设计可以把一次预约和具体的人、疫苗、医生及时间关联起来。

核心表	关键关联字段	用途
vaccine_information	vaccine_no	保存疫苗编号、名称、类型、厂家、适合年龄等基础信息。
appointment_record	order_no、user_no、doctor_no、vaccine_no	保存一次预约的主体、医生、疫苗和时间。
vaccination_record	user_no、vaccine_no、doctor_no	记录实际接种结果，支撑历史追踪。
vaccination_exception_information	record/order 关联字段	单独记录异常情况，便于查询与后续处理。
warehousing_management / ex_warehouse_management	vaccine_no、数量、时间	记录疫苗入库和出库，支撑库存核对。

数据库设计建议 业务表不要只保存名称等可变文本，最好同时保存稳定的主键或业务编号；订单号、疫苗编号、医生编号等字段应建立唯一约束或普通索引，并根据实际查询路径设计联合索引。

图 4　疫苗信息列表：支持按编号、名称等条件检索和维护

6. 关键接口实现

6.1 登录：账号校验、状态校验与令牌生成

论文中的登录接口支持用户名、邮箱或手机号登录。核心流程是：定位用户 → 校验用户组与审核状态 → 校验账号状态 → 校验密码 → 生成访问令牌。下面代码按论文实现进行了精简，便于阅读。

Java · 登录核心逻辑（根据论文代码精简） @PostMapping("login") public Map<String, Object> login(@RequestBody Map<String, String> data) {     String username = data.get("username");     String email = data.get("email");     String phone = data.get("phone");     String password = data.get("password");       List<User> users = service.findByAccount(username, email, phone);     if (users == null || users.isEmpty()) {         return error(30000, "用户不存在");     }       User user = users.get(0);     if (!service.isApproved(user) || user.getState() != 1) {         return error(30000, "用户未通过审核或账号不可用");     }       if (!user.getPassword().equals(service.encryption(password))) {         return error(30000, "账号或密码不正确");     }       AccessToken token = tokenService.create(user.getUserId());     return success(Map.of("user", user, "token", token.getToken())); }

这个接口已经考虑了“用户不存在、审核未通过、账号冻结、密码错误”等分支，比只判断用户名和密码更完整。不过正式项目不建议使用普通 MD5 方案保存密码，应该采用 BCrypt、Argon2 等带盐哈希算法。

6.2 注册：重复账号校验与密码加密

Java · 用户注册核心逻辑 @PostMapping("register") public Map<String, Object> register(@RequestBody User user) {     if (service.existsByUsername(user.getUsername())) {         return error(30000, "用户已存在");     }       user.setUserId(null);     user.setPassword(service.encryption(user.getPassword()));     service.save(user);     return success(1); }

注册接口的关键点并不是 save()，而是注册前的唯一性校验、字段合法性校验、密码安全处理和默认角色分配。建议在数据库中同时给 username、phone、email 等字段建立唯一约束，防止并发注册时只靠应用层判断。

6.3 列表查询：筛选、排序与分页

Java · 列表分页接口 @GetMapping("/get_list") public Map<String, Object> getList(HttpServletRequest request) {     QueryConfig config = service.readConfig(request);     QueryFilter filter = service.readQuery(request);     return success(service.selectToPage(filter, config)); }

后台列表通常要同时支持关键字筛选、排序和分页。实际开发中应优先使用 MyBatis 参数绑定或条件构造器，不要直接拼接来自请求参数的 SQL 字段和值，避免 SQL 注入和越权查询。

7. 页面实现效果

系统前台和后台采用不同的功能入口。后台以数据维护为主，前台更强调查询、预约和记录查看。界面并不需要追求复杂动画，信息层级清晰、表单字段准确、操作反馈明确更重要。

图 5　疫苗详情页：集中展示疫苗编号、名称、类型、厂家和适合年龄等信息

图 6　预约接种页面：填写预约信息并提交业务单据

8. 测试重点

论文主要通过注册和登录测试用例验证功能。为了让测试更贴近真实业务，可以至少覆盖以下场景。

测试场景	预期结果	关注点
注册信息不完整	阻止提交并提示缺失字段	前后端均需校验。
用户名已经存在	提示重新填写	数据库唯一约束。
账号不存在或密码错误	拒绝登录	错误信息避免泄露过多细节。
用户未审核或账号被冻结	拒绝登录	状态判断要在密码校验之外。
预约时间或医生不可用	阻止生成冲突预约	需要时间冲突检测。
疫苗库存不足	限制预约或给出提示	预约与库存要保持一致。

9. 从课程设计走向真实项目，还需要补什么？

作为毕业设计，该系统已经覆盖了完整的管理流程；如果要进一步接近真实生产环境，建议从以下方面继续升级。

• 安全：使用 BCrypt/Argon2 保存密码，统一鉴权与 RBAC 权限校验，接口增加限流和登录失败锁定。
• 数据合规：对儿童姓名、联系方式等敏感数据进行脱敏展示、加密传输和最小权限访问。
• 审计：记录谁在什么时间修改了预约、接种、异常和库存数据，关键操作保留审计日志。
• 业务一致性：预约成功、接种确认、库存扣减应放在清晰的事务边界中，避免部分成功。
• 提醒能力：增加预约前提醒、逾期提醒和库存预警，但所有提醒文案应避免替代专业医疗判断。
• 部署与备份：区分开发、测试和生产配置，设置数据库定期备份、异常监控和恢复演练。

10. 总结

这个项目的价值不只在于完成一套 Spring Boot + Vue.js 管理系统，更在于把多个看似独立的 CRUD 模块连接成可追踪的业务流程：疫苗信息提供基础数据，预约生成业务单据，医生处理后形成接种记录，异常信息和库存记录补全后续管理。

对于正在准备 Java 毕业设计或练习前后端分离项目的同学，这类系统很适合训练需求拆解、角色权限、数据库建模、接口设计和测试用例编写。你在做类似项目时，更关注数据库设计、权限控制，还是预约流程？欢迎交流。

—— 正文结束 ——