首页 / 资讯中心 / 文章详情

SpringBoot+Vue疫苗发布与接种预约系统核心设计与实战解析

SpringBoot+Vue疫苗发布与接种预约系统核心设计与实战解析 ★ FEATURED ARTICLE
不管你是准备拿它当毕设还是想快速搞懂一个典型企业级前后端分离项目是怎么串起来的这套基于 SpringBoot Vue 的疫苗发布和接种预约系统都值得仔细过一遍。项目里不光包含完整源码还配套了 MySQL 的 SQL 脚本和接口文档基本把 Java Web 毕设里会用到的东西都带上了——用户端、管理端、预约流程、号源控制、权限校验一个业务闭环下来能学到的远不止“写几个增删改查接口”。我拿到项目后先做的事不是急着启动而是把数据库表和核心接口捋了一遍。原因很简单预约类系统最怕的是并发下“超卖”和“预约状态混乱”如果表设计不合理、事务边界没划清楚后面接口写得再漂亮也是白搭。这篇就把我对这个项目的理解、启动步骤、功能拆解、踩坑点以及答辩可能被问的问题一起整理出来给准备做同类项目的朋友一个参考。1. 项目整体思路与模块拆解1.1 项目到底解决了什么问题这个系统核心解决的是“疫苗信息发布”和“接种预约”两个环节的线上化。以前线下预约靠电话、排队信息不透明、号源不可控管理员想统计接种数据也非常麻烦。换成线上系统后管理员可以在后台维护疫苗批次、库存、有效期发布某一天的接种场次和可预约数量普通用户在小程序或者网页端注册登录后看到已发布的疫苗场次选择合适的日期和时段提交预约到点再去现场接种。整个业务可以拆成四条主线用户侧注册、登录、查看疫苗资讯、查看接种公告、预约、取消预约、查看个人预约记录。管理侧疫苗信息管理、库存批次管理、接种场次发布、预约审核/核销、预约记录查询与统计。公告侧疫苗发布公告、接种注意事项、系统通知类似一个轻量 CMS。系统侧用户管理、角色权限管理、操作日志。从功能量来看这差不多是毕设里中等偏上的复杂度既有基础的信息管理又有带业务规则的预约下单还涉及权限控制非常适合用于 Java Web 方向的毕业设计展示。1.2 技术栈选型为什么是 SpringBoot VueSpringBoot 解决了传统 SSM 项目里大量 XML 配置的问题内嵌 Tomcat打 jar 包就能跑部署特别省心。Vue 做前端页面很顺组件化拆分让页面维护比 JSP 时代舒服太多。前后端分离后后端只出 JSON 接口前端通过 Axios 调接口职责清楚也方便以后把前端换成小程序或者 App。选型上有一点要注意项目里如果用的是 Vue 2 加 Element UI那大概率配套的是 SpringBoot 2.x。SpringBoot 3 要求 JDK 17并且部分第三方依赖的兼容方式不一样所以跑项目前一定先确认 JDK 版本。如果你本机装的是高版本 JDK建议直接在配置里把后端 JDK 改为 1.8 或者 11这样可以少踩很多坑。2. 数据库设计与 SQL 脚本解读2.1 核心表有哪些拿到 SQL 脚本后建议先不要急着执行先打开看下表结构。这个项目的核心表大概包括这几类用户表保存账号、密码、姓名、证件类型、证件号、手机号、角色标识。密码通常是加密存储的不要用明文。疫苗表维护疫苗名称、生产企业、批号、接种剂次、适用人群、规格、库存总量、剩余库存、有效期。接种场次/预约计划表保存接种点、日期、时间段、可预约总数、已预约数、剩余号数、状态。预约记录表关联用户和场次保存预约时间、预约状态待接种/已接种/已取消/已过期、现场核销码或二维码。公告通知表用于疫苗发布和接种注意事项的内容展示。角色权限相关表如果项目用了 Spring Security 或 Shiro通常还会有角色表、菜单表、用户角色关联表。这些表之间的关系也很好理解用户和预约记录是一对多预约记录和接种场次是多对一场次和疫苗是多对一。只要理清这三条关系整个数据库的设计思路就通了。2.2 SQL 脚本执行要改的三处地方很多同学启动项目时报数据库连接失败基本都是下面三处没改-- 1. 建库用 utf8mb4 而不是 utf8 CREATE DATABASE vaccine_appointment DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;第一处是字符集疫苗名称、公告内容里如果有生僻字或者特殊符号utf8mb4 更稳妥。第二处是数据库账号密码脚本本身没有账号配置要在后端application.yml里改成你自己的库名、用户名、密码。第三处是时区问题MySQL 8 的驱动对时区要求比较严格连接串里最好带上serverTimezoneAsia/Shanghai否则插入时间可能报错。另外脚本里如果带了初始管理员数据账号一般会在 README 或者 SQL 注释里给出。默认管理员密码大多是admin123或者123456这样的简单密码第一次登录后记得在系统里修改掉答辩现场如果被老师看到弱口令观感不太好。3. 环境准备与快速启动全过程3.1 环境要求我实际运行这套项目使用的环境可以参考但不一定完全一致环境版本建议JDK1.8 或 11Maven3.6MySQL5.7 或 8.0Redis如果项目用到缓存/分布式锁再装纯预约扣库存可不装Node.js14 或 16配合 Vue2IDEIDEA 2020 / VS Code注意如果前端用的是 Vue CLI 4Node 版本太高可能会在node-sass编译阶段报错。这时候最省事的办法不是换 Node而是把package.json里的node-sass改成sass或者用npm install时指定镜像源。3.2 后端启动的五个步骤后端启动顺序并不复杂关键是别手快先用 Navicat 或者命令行执行 SQL 脚本完成建库建表。用 IDEA 打开后端目录等 Maven 把依赖下载完。修改application.yml里的数据源配置确认端口没被占用。如果项目用了 Redis先启动 Redis 服务并确认redis.host和redis.port配置正确。启动 Application 主类看到Started ... Application的日志就说明成功。启动时如果报Failed to configure a DataSource大概率是数据库连接没配对如果报端口被占用在后端配置中修改server.port比如改成 8081。前端里如果有写死的后端地址也要同步改掉。3.3 前端启动的四个步骤前端部分按顺序执行下面四条命令npm install npm run servenpm install偶尔会卡住可以换成npm install --registryhttps://registry.npmmirror.com启动后终端会提示访问地址默认一般是http://localhost:8080。如果项目里配置了代理在vue.config.js里可以看到/api开头的请求被代理到哪个端口前端访问和后端端口未必一致这个要留意。4. 核心功能实现疫苗发布与接种预约4.1 疫苗发布不是简单的“新增一条数据”“疫苗发布”这个功能听起来就像普通的新增记录实际做起来有几个隐含业务规则。比如发布前要确认疫苗库存充足发布的场次日期不能早于当前日期同一接种点在同一时间段不能重复发布两个场次状态要支持“草稿、已发布、已关闭”。如果项目里没有做这些校验动手改的时候可以这样补前端在提交表单时校验日期和库存后端在 Service 层再校验一次。后端校验才是真正的防线前端校验只是用户体验。判断重复场次的 SQL 可以理解为select count(*) from vaccine_schedule where site_id #{siteId} and schedule_date #{scheduleDate} and start_time #{startTime} and status ! CLOSED只要查出的数量大于 0就直接抛业务异常提示已有场次不要再往数据库里插数据。4.2 预约流程的本质是什么预约流程本质上是一个“库存扣减 状态流转”的过程。用户提交预约时后端要做的动作包括先判断用户是否登录并确认用户的身份信息是否完善。查询场次确认场次状态是已发布且预约时间还在可预约范围内。判断剩余号数是否大于 0并校验该用户是否已经预约过同一场次。扣减号源。生成预约记录初始状态为“待接种”。返回预约凭据比如预约码。这里最容易忽略的是“幂等性”也就是用户手抖点了两次提交不能生成两条预约记录。简单方案是给预约记录表加唯一约束比如user_id schedule_id联合唯一第二次再插入时数据库会直接报错。更好一点的做法是提交预约前先查一次是否已存在再配合事务锁把校验和插入放在同一个事务里。4.3 防超卖用数据库原子更新就够了毕设答辩时老师大概率会问“并发预约你怎么控制”。如果项目里没有引入 Redis直接用数据库就能防超卖。核心不是select再update而是把剩余号数的判断放进 update 条件里update vaccine_schedule set remaining_count remaining_count - 1 where id #{scheduleId} and remaining_count 0这条 SQL 执行后如果返回影响行数为 1说明扣减成功如果返回 0说明剩余号数已经不足。由于数据库更新会自动加行锁这种方式在低并发场景下完全够用并且不需要额外引入中间件。配合事务把“扣减号源 创建预约记录”放在同一个方法里加上Transactional注解基本就稳了。如果你想展示更高阶的设计可以在场次表加一个version字段做乐观锁或者引入 Redis 做库存预热和 Lua 扣减。但这些属于加分项对毕设来说不是必须前提是你自己能够把这个方案讲清楚否则反而容易被老师追问到答不上来。5. 接口文档与实际开发中的权限控制5.1 接口文档怎么看、怎么用项目自带的接口文档一般有两种形式一种是 Swagger 或 Knife4j 生成的在线接口页面另一种是单独的 Markdown/Word 文档。如果是 Knife4j后端启动后访问http://localhost:端口/doc.html就能看到在线接口列表可以直接在页面里调试接口比 Postman 还方便。接口文档里的内容重点关注三块请求路径和请求方法比如GET /api/vaccine/list。请求参数和参数位置是放在 URL 的 query 里还是放在请求 body 的 JSON 里。响应结构很多项目会用统一响应体包装比如{code:200, message:成功, data:...}。看接口文档时要特别注意“参数必填项”后端大多数框架都有参数校验比如NotBlank(message 疫苗名称不能为空)。如果漏传参数接口会返回 400 或者业务码但不一定是系统崩溃学会看响应里的 message 是排错的关键。5.2 JWT 登录与权限设计前端每次请求后端接口都要在请求头里带Authorization: Bearer token。登录后后端会生成一个 JWT 字符串返回给前端前端存在localStorage或sessionStorage里之后请求通过 Axios 拦截器统一加请求头。权限控制如果用的是 Spring Security常见的配置是http.authorizeRequests() .antMatchers(/api/auth/**).permitAll() .antMatchers(/api/admin/**).hasRole(ADMIN) .anyRequest().authenticated();如果用的是拦截器思路也类似先放行登录注册接口再校验 token再识别角色。这个逻辑看起来简单但有两个坑必须注意一个是静态资源和预检请求 OPTIONS 要放行否则前端跨域请求会直接被拦另一个是 token 过期后的处理前端需要在拦截器中根据返回码跳转到登录页同时清理本地会话。6. 运行项目时常见的五个坑与排查思路6.1 后端启动失败先看异常信息再动手不要一上来就百度。常见原因有数据库连接不上检查application.yml里的 URL、账号、密码。端口被占用Windows 下用netstat -ano | findstr 8080查看进程或者直接改端口。Maven 依赖没下载完IDEA 里刷新 Maven 项目并把本地仓库的lastUpdated文件清掉再重新拉取。Lombok 插件没装好启动时报找不到log对象或者 getter/setter先在 IDEA 插件市场安装 Lombok并开启注解处理。6.2 前端页面空白或请求 404页面空白先按 F12 看控制台报错。如果控制台报Cannot read property xxx of undefined通常是后端返回的数据结构和前端预期不一致用接口对比文档看一下字段名。请求 404 时看请求路径是相对路径还是绝对路径注意 Vue 项目里publicPath如果配置不对打包后资源路径也会出问题开发模式下一般不用管。开发模式下最常见的是跨域报错。后端如果没配置跨域前端代理可以解决在vue.config.js里添加 devServer 代理把/api转发到后端地址这样前端请求同源后端不需要单独处理 CORS。6.3 预约报错但没提示具体原因排查思路按下面顺序走看后端控制台有没有 SQL 异常特别是外键约束和字段不存在。看前端打印的响应数据有没有统一返回的 message。用接口文档里的调试功能单独调一次预约接口排除前端页面逻辑的干扰。检查数据库里场次的状态是不是“已发布”很多预约失败是因为前置状态不对。检查用户有没有重复预约联合唯一约束会返回Duplicate entry这种异常需要被捕获并转换成友好提示。这类业务异常要用自定义异常处理否则数据库底层的异常直接抛给前端用户体验很差。例如可以建一个BusinessException统一在 ControllerAdvice 里捕获返回给前台一个可读的message。7. 答辩前我建议重点准备的知识点如果你是拿这个项目做 Java Web 毕业设计功能做完只是第一步答辩时老师更关心的是“你有没有真正理解这套系统”。下面几个问题建议提前准备答案为什么用 SpringBoot 而不用传统的 SSM围绕简化配置、内嵌容器、生态整合来答。数据库表为什么要拆成用户表、场次表、预约记录表用第三范式、避免数据冗余来答。并发下如何防止同一个号源被重复预约往上翻到第 4.3 节那一条原子更新 SQL能把这条讲清楚基本就过关了。如果预约人数突然暴增系统会怎么表现可以从数据库行锁竞争、接口响应变慢、前端超时这几个角度聊再提出加缓存、限流、消息队列等优化方向。前端如何做路由权限控制比如根据用户角色动态生成路由表或者在路由守卫里判断 token 是否有效。我的切身体会是这类项目的难点从来不是某个技术点本身而是把业务规则和技术方案串起来。比如疫苗发布和接种预约看起来是两个模块实际数据是联动的接口文档看起来只是交付物真排错时比什么都管用。如果你能顺着“数据库设计 - 接口设计 - 前端页面 - 部署验证”这条线把它完整走一遍这套源码能给你带来的提升绝对超过“复制粘贴跑通”的效果。最后分享一个我自己的小习惯拿到这种带 SQL 脚本的项目第一件事不是启动而是先打开数据库看表注释和字段注释。注释写得越细说明项目结构越规范你后面读代码、改功能、写论文都会轻松很多。如果发现某些字段没有注释稍微花点时间补上答辩时老师翻数据库也不会觉得难看。这套系统本身就是很好的学习素材关键是别只停在“能跑”的层面多问几个为什么收获会完全不一样。
阅读完成 · 觉得有帮助?
咨询建站