1. 疫苗预约这个场景到底难在哪里做接种预约系统之前我先把线下接种点的真实工作流程捋了一遍。社区接种点每天要做的事情远比想象中繁琐统计各疫苗库存、安排接种台次、通知接种者时间、核对身份信息、记录接种批次、处理爽约和改期一套流程下来全是人工操作。更麻烦的是疫苗这种特殊商品和其他预约场景有本质区别。电影院选座、餐厅排号资源是无限的人到了就消费。疫苗不一样每一支疫苗都有严格的批次管理、冷链存储要求和效期限制一个批次开封后必须在规定时间内用完否则就是损耗。而且不同疫苗的接种间隔要求完全不同新冠疫苗、HPV疫苗、流感疫苗、儿童规划疫苗各自的剂次间隔、适用人群、禁忌症都不一样。这就决定了疫苗预约系统绝不是一个简单的选时间点确认的CRUD它背后至少要处理好四件事库存与排期的联动。接种点按周或者按月设置放号计划每个号源对应某一天的某个时间段但这个时间段能放多少号取决于当天分配到多少支疫苗、有几个接种台、每个台次处理一个接种者需要多久。接种资格的校验。不是谁都可以约任何疫苗。HPV疫苗有年龄限制新冠疫苗有剂次间隔要求儿童疫苗要严格按出生日期计算应种月龄。系统得在用户提交预约时自动完成这部分校验不能等医生现场发现再劝退。爽约和改期处理。线下接种点最头疼的就是爽约率。约了不来疫苗开封了没人打直接浪费。系统要么设计保证金机制要么利用微信消息通知反复提醒要么限制爽约次数总之要把号源利用率提上去。接种记录的闭环。预约完成只是起点接种后的留观记录、接种批次归档、第二针第三针的自动提醒都要在这个系统里形成闭环否则就只是个预约工具称不上管理平台。想清楚这些之后整体方案也就有方向了后端用SpringBoot构建RESTful API小程序端负责用户交互和预约操作管理端做排期、库存和记录管理。下面是完整的落地过程。2. 技术选型的逻辑为什么是SpringBoot加微信小程序2.1 后端框架SpringBoot解决的是开发效率问题选SpringBoot不是因为它流行而是它确实适合这种业务系统。疫苗接种预约管理本质上是一个典型的业务管理系统CRUD多、权限体系明确、需要对接微信生态SpringBoot在这一类项目里几乎是标准解。具体来说SpringBoot在这套系统里承担四层职责接口层对外暴露预约、查询、取消、签到、记录等RESTful接口统一返回格式和异常处理。所有接口都走HTTP JSON协议小程序端直接调用。业务层把预约资格校验、库存扣减、状态流转、消息推送这些核心逻辑隔离在Service层保证Controller只做参数接收和响应封装。这部分是整个系统的重心后面会展开讲。数据层通过MyBatis-Plus操作MySQL数据库利用其内置的CRUD方法减少重复代码复杂查询走自定义SQL。疫苗批次、排期计划、预约单、接种记录都要落库。基础设施整合Redis做分布式锁和热点缓存Quartz或Spring Task做定时任务比如每天凌晨自动关闭过期号源、发送接种提醒这些在SpringBoot里都有非常成熟的 starter 支持。和SSH老框架比SpringBoot最大的优势是约定大于配置——你不用花时间纠结xml配置文件的写法依赖管理由starter自动完成本地开发一个SpringBootApplication启动类就能跑起来。对毕业设计或者中小型项目来说这套组合拳足够高效。2.2 前端载体小程序比H5和App更匹配接种场景疫苗预约的使用场景非常分散用户可能在社区公告栏看到通知可能在家庭群里被转发可能临时接到短信提醒。让用户为了预约专门下载一个App转化率一定很低做H5页面虽然免安装但入口太深需要分享链接才能到达。微信小程序的优势恰好击中这个需求打开微信就能搜到、扫码就能进入、用完即走。而且小程序天然具备微信登录的能力不需要用户重新注册账号——政务民生类场景里能用微信身份直接登录是最省事的方案用户不需要额外设置密码也不会因为忘记密码流失。技术上我选择原生小程序开发不用uni-app或Taro跨端框架。原因是这个项目只需要跑在微信平台没有多端分发诉求原生框架的调试工具和API文档最完整遇到问题最容易搜到解决方案。跨端框架的优势在于一套代码多端运行但代价是框架层可能有坑对毕设或者单人项目来说原生开发其实更稳。2.3 前后端通信RESTful接口约定前后端分离的核心是接口约定。我用的方案是基础路径/api/v1 鉴权方式token登录后由后端签发请求头Authorization携带 返回格式{ code: 200, message: ok, data: {} }不要小看这个统一返回格式前后端联调时90%的沟通成本都浪费在这个接口到底返回什么结构上。提前定义好code的语义200成功、401未登录、403无权限、400参数错误、500服务异常再封装一个通用的ResultT类后端所有接口统一返回这个结构前端在网络请求封装层统一拦截处理效率能提升一大截。小程序的网络请求封装也很简单wx.request包一层就行// utils/request.js const request (url, method, data) { return new Promise((resolve, reject) { wx.request({ url: ${BASE_URL}${url}, method, data, header: { Authorization: wx.getStorageSync(token) || }, success: (res) { if (res.data.code 200) { resolve(res.data.data); } else if (res.data.code 401) { wx.navigateTo({ url: /pages/login/login }); } else { wx.showToast({ title: res.data.message, icon: none }); reject(res.data); } }, fail: reject }); }); };这里有个容易忽略的细节token过期后不能只在控制台打日志一定要统一跳转到登录页否则用户会以为系统卡死了。这个笔者在实际测试中就踩过——明明接口报401页面上没有任何反馈白屏了好几秒体验非常糟糕。3. 核心业务链路的实现排期、预约、核销与提醒3.1 排期生成号源从哪来接种点的排期不是随便填几个日期就完事它要根据疫苗库存和接种能力来算。我在数据库里设计了vaccine_stock疫苗库存表和schedule_plan排期计划表两张核心表vaccine_stock记录每个批次的疫苗名称、库存数量、生产日期、效期、所属接种点。schedule_plan记录某一天某个接种点放出的预约名额关联具体的疫苗批号和可预约数量。当管理员在管理端创建排期时系统自动校验当天该疫苗的可用库存如果排期放号数量大于库存数量直接拦截并提示。这个校验逻辑很简单但非常关键——疫苗是实物放号放多了没法履约放少了浪费资源。实际开发中我还做了一个增强优化每个schedule_plan关联的疫苗批号在用户预约成功后就把对应批号的库存预占掉。也就是说用户下单成功即视为锁定一支疫苗库存表立即扣减。这样管理员在后台看到的库存永远是真实剩余量而不是理论剩余量扣除未核销预约这种绕来绕去的计算方式。排期的时间粒度我建议设成上午/下午/晚上三个时间段而不是精确到具体时刻。原因有二一是接种点现场的节奏很难精确到分钟医生可能因为某个接种者不良反应观察时间稍长而延误按时间段预约容错性更好二是从产品角度看用户对时间粒度的预期不需要那么精确只要知道上午还是下午去就行预约转化率反而更高。3.2 预约提交资格校验的三道关卡预约接口是整个系统最核心的接口也是并发压力最大的接口。一个热门疫苗的号源放出后几十上百人同时点击处理不好就会出现超卖。我的预约流程是三层校验第一层用户身份校验。判断用户是否已登录、是否已完成实名信息登记姓名、身份证、手机号。很多预约系统死在这步——用户点击预约才发现要填一堆资料直接放弃。优化方案是用户首次进入小程序时就引导完善个人信息后续预约无需重复填写。第二层业务资格校验。根据用户性别、出生日期、历史接种记录判断是否符合该疫苗的接种条件。比如HPV九价疫苗要求女性且在适龄范围内新冠疫苗第二针要求距离第一针超过21天这类规则全部做成可配置的校验策略不同疫苗挂不同的校验器。第三层库存与并发校验。先查缓存再查数据库确认该时间段还有剩余号源然后利用Redis分布式锁防止并发超卖// 伪代码预约提交核心逻辑 public void createAppointment(AppointmentRequest request) { // 1. 业务资格校验 validateEligibility(request.getUserId(), request.getVaccineId()); // 2. 分布式锁锁粒度排期计划ID String lockKey appointment:lock: request.getSchedulePlanId(); boolean locked redisLock.tryLock(lockKey, 5, TimeUnit.SECONDS); if (!locked) { throw new BusinessException(当前预约人数过多请稍后重试); } try { // 3. 检查剩余名额 int remain schedulePlanMapper.getRemainCount(request.getSchedulePlanId()); if (remain 0) { throw new BusinessException(该时间段名额已满); } // 4. 扣减库存、生成预约单 schedulePlanMapper.decreaseRemainCount(request.getSchedulePlanId()); appointmentMapper.insert(buildAppointment(request)); // 5. 发送微信订阅消息提醒 wxMessageService.sendAppointmentSuccessNotice(request); } finally { redisLock.unlock(lockKey); } }分布式锁在这个场景里是必须的。有人可能觉得用数据库行锁或者乐观锁也能做但实际并发量一上来数据库锁会导致接口响应时间急剧膨胀。当然如果只是毕业设计或者演示用的Demo用数据库的UPDATE ... WHERE remain_count 0也能扛住原理都是避免超卖只是性能和体验的差别。还有一点容易忽略预约成功后一定要异步发送微信订阅消息不能放在主流程里同步执行。微信订阅消息的发送接口有时会有几秒延迟同步发送会把预约操作的响应时间拖长用户觉得卡顿。用Spring的Async注解丢到线程池里处理主流程只负责保存数据和返回结果。3.3 核销签到闭环保关键的一环用户按照预约时间到接种点后医护人员需要核验预约信息并完成签到。小程序端提供一个我的预约页面展示预约二维码管理端用扫码枪或者手机摄像头扫码识别预约单号后自动完成核销。核销的核心逻辑是状态流转。预约单的状态我定义成五个WAIT_APPOINT待预约→ BOOKED已预约→ CHECKED_IN已核销→ COMPLETED已完成 ↘ CANCELLED已取消核销操作就是把BOOKED状态改成CHECKED_IN同时生成一条接种记录关联疫苗批次、接种部位、接种医生等信息。这一步做完管理员在后台就能看到今日接种数据包括已预约数、已核销数、未到数爽约率一目了然。实际开发中核销部分有一个容易踩的坑二维码内容不能直接填预约单ID否则被人恶意遍历ID就能伪造预约。我的做法是生成一个带签名的随机串比如MD5(预约单号 随机盐)扫码后后端验证签名有效才放行。虽然小程序端做了登录鉴权但管理端扫码入口是公开页面这种安全设计能挡掉大部分低级攻击。3.4 智能提醒让爽约率降下来的实用技巧接种提醒是业务里最简单但用户感知最强的功能。预约成功通知、接种前一天提醒、接种后留观提醒、第二针到期提醒这几个节点做好用户对系统的好感度会明显提升。技术实现用的是微信订阅消息核心是wx.requestSubscribeMessage接口。注意这个接口有个一次性订阅的特性——用户每次点击授权只能接收一次消息推送想让用户持续接收提醒就得在每次关键操作时都引导用户重新订阅。实际操作中的经验是把订阅请求放在用户完成预约的瞬间弹窗因为这时候用户的期望值最高完成预约后自然希望收到后续提醒授权通过率最高。如果单独为订阅做一个页面让用户主动勾选通过率通常很差。提醒任务用定时任务实现每天固定时间扫描预约单表找出明天有预约的订单批量发送订阅消息。这里有个性能小优化不要一条一条发微信订阅消息接口支持批量通过openid列表发送一次可以处理几千个用户。4. 数据模型设计关键表和字段背后的业务含义数据模型是项目的根基设计不好后面改起来非常痛苦。我把这套系统的核心表拆开讲一遍每张表的设计逻辑都对应前面提到的业务需求。4.1 核心数据表用户表userid, openid(微信唯一标识), nickname, avatar, id_card(身份证号), phone, gender, birth_date, address, create_time, update_time身份证号和出生日期是接种资格校验的基础数据。需要注意身份证、手机号属于敏感信息数据库里要么加密存储要么至少做脱敏展示接口返回给前端时不能直接全量返回身份证号。疫苗表vaccineid, name(疫苗名称), type(疫苗类型新冠/HPV/流感/儿童规划疫苗), manufacturer(生产厂家), description, interval_days(剂次间隔天数), max_doses(最大接种剂次), applicable_scope(适用人群范围), statusinterval_days和max_doses这两个字段是资格校验规则的数据来源。比如新冠疫苗interval_days21用户在预约第二针时系统自动计算第一针接种日期加21天后是否小于等于当前日期不满足就直接拒绝。疫苗库存表vaccine_stockid, vaccine_id, batch_no(批号), stock_count(库存数量), production_date, expiry_date, site_id(所属接种点), status批号和效期管理是我特别强调的。社区卫生服务中心检查时必查疫苗批号追溯每支疫苗从出厂到接种给谁必须能完整追踪所以vaccine_stock必须保留batch_no字段接种记录也必须关联到批号。排期计划表schedule_planid, vaccine_id, stock_id, site_id, plan_date(放号日期), time_slot(时间段上午/下午/晚上), total_count(总号源), remain_count(剩余号源), statusremain_count是预约并发控制的关键字段所有预约操作都围绕它做扣减。这里我做了缓存优化热门疫苗的排期信息放在Redis里键设计为schedule:info:{planId}值存剩余号源数量预约时先查Redis再落库显著降低数据库压力。预约表appointmentid, user_id, vaccine_id, schedule_plan_id, appointment_no(预约单号), status(BOOKED/CHECKED_IN/CANCELLED/COMPLETED), appointment_date, time_slot, check_in_time, cancel_reason, create_time预约表是整个业务流的主线所有状态流转都围绕它进行。appointment_no生成规则我用了时间戳加随机数的组合保证唯一且不可预测。接种记录表vaccination_recordid, user_id, vaccine_id, stock_id, doctor_id, vaccination_date, dose_number(第几剂), injection_site(接种部位), batch_no(疫苗批号), adverse_reaction(不良反应记录), status接种记录是疾控中心要求保留的档案数据也是后续资格校验的判据。用户端展示我的接种记录查询接口就从这张表取数。4.2 设计取舍的思考数据模型设计过程中有一个值得分享的取舍预约表和时间段的解耦。最初我的设计是预约表直接存appointment_time精确到分钟后来和接种点医生聊过之后才发现实际工作中预约时间根本无法精确到分钟预约9:00的用户可能9:30才到前面的号因为各种原因顺延很正常。改成时间段模型后用户看到的是7月25日上午医生端看到的是当天上午的预约名单按到达顺序核销就行。这个改动看似简单但把整个系统的可用性提升了不止一个档次——从那以后就没有出现过预约超时未到系统自动取消这种逻辑问题。另一个取舍是是否引入site_id接种点维度。如果你做的是一个社区级别的平台只有单个接种点可以不用这个字段但如果你想把这个项目扩展成区域级平台一个区多个接种点从第一天就保留site_id字段后续扩展会容易很多。我的建议是至少预留这个字段不要为了省事把所有表混在一起后面想加维度还得动表结构。5. 消息通信与权限控制小程序端容易忽略的两个细节5.1 登录鉴权与token管理小程序登录流程遵循微信官方标准wx.login获得code后传给后端后端调用code2Session接口换取openid然后签发自定义token返回给小程序。token存到wx.setStorageSync里每次请求带上。这个流程本身不复杂但有一个细节容易被新手忽略code2Session接口的网络耗时。微信的接口调用在国内网络环境下通常100-300毫秒如果每次进入小程序都先走一遍这个流程再加载页面用户会觉得加载很慢。优化方案是openid获取成功后缓存在Redis里设置过期时间比如7天下次用户进入小程序时先检查本地token是否有效有效就跳过登录流程直接进入首页。只有token失效时才重新走wx.login换取新code。具体的完整登录流程我在实现时分了三步首次进入调用wx.login获取code → 后端换openid → 查询用户表是否存在不存在则创建默认用户 →签发token。信息完善用户进入个人信息页补充身份证、出生日期、手机号等必填信息在需要展开接口层时直接声明PreAuthorize或自定义拦截器校验用户权限角色。管理端接口统一加上管理员角色校验普通用户token访问管理接口直接拒绝。后续访问小程序请求头带上token后端通过拦截器解析token拿到用户身份不再每次都查数据库。5.2 用户角色与权限设计这套系统天然有两种角色普通用户接种者和管理员接种点医护人员。我用Spring Security加上JWT实现角色权限控制。后端实现方式不复杂继承OncePerRequestFilter写一个JWT过滤器在doFilterInternal里解析请求头的token拿到用户ID和角色信息后注入Spring Security的上下文public class JwtAuthenticationFilter extends OncePerRequestFilter { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { String token request.getHeader(Authorization); if (StringUtils.hasText(token) token.startsWith(Bearer )) { // 解析token获取用户ID和角色 Claims claims JwtUtil.parseToken(token.replace(Bearer , )); // 构造Authentication对象存入SecurityContext // ... } filterChain.doFilter(request, response); } }管理端接口全部挂在/api/v1/admin/**路径下Spring Security配置规则时对该路径设置hasRole(ADMIN)普通用户即使构造请求也访问不到管理端接口。小程序端的权限控制主要靠页面跳转限制和按钮隐藏。管理员登录小程序后通过一个切换身份按钮进入管理页。管理页的入口仅在用户角色为ADMIN时显示避免普通用户误入管理页面。6. 部署与数据安全上线前必须处理的三件事6.1 线上环境的应用部署方案项目开发完成后部署方案我建议采用单机加Docker Compose足够应对中小型社区接种点的访问量。如果你只是做毕业设计可以简化到在服务器上直接跑Java进程加MySQL不需要上Docker编排。一个参考的部署结构如下后端服务打包成Jar包运行推荐用nohup java -jar或者注册成systemd服务监听8080端口。数据库MySQL 8.0单独服务器或者本机都可以注意开启远程连接权限并修改默认密码策略。Redis负责分布式锁和缓存独立运行设置访问密码。Nginx做反向代理把/api/路径转发到后端服务同时托管小程序的静态资源和管理员H5页面。生产环境一个非常关键的点是配置文件不能把密码写死。至少要区分application-dev.yml和application-prod.yml数据库密码、Redis密码、小程序AppSecret等在本地和线上分别配置。SpringBoot的ConfigurationProperties绑定方式配合环境变量注入是我比较推荐的做法# application-prod.yml spring: datasource: password: ${DB_PASSWORD} redis: password: ${REDIS_PASSWORD} wechat: appid: ${WECHAT_APPID} secret: ${WECHAT_SECRET}启动时通过--spring.profiles.activeprod指定环境机密信息全部来自环境变量而不是写死在yml里。6.2 数据脱敏与隐私保护疫苗接种系统涉及大量个人敏感信息姓名、身份证号、手机号、健康记录。上线前不管别人有没有要求以下几条必须做到日志脱敏Controller层和Service层不要打印身份证号、手机号明文日志只打印掩码版本如110***********1234。之前我调试时随手打了整个用户对象后来回看日志冷汗直冒。接口脱敏返回给前端的数据中身份证号、手机号、地址等字段要么不返回要么只返回部分手机号中间四位打码。数据库查询时可以用SQL函数处理或者后端序列化时统一脱敏。授权最小化管理端账号按角色分配权限值班医生账号只允许查看当日预约和接种记录不具备修改疫苗库存和删除预约的权限。数据安全是合规底线不是有空再补的功能。6.3 微信小程序审核注意事项小程序上线前需要通过微信审核医疗健康类目对资质要求非常严格。如果你是以个人开发者身份注册小程序类目只能选工具或者生活服务一旦涉及疫苗、医疗相关内容审核大概率会被驳回。实际操作中的经验是先以个人身份注册开发版体验等流程完整跑通后再提交给有医疗资质的机构主体去重新注册发布。测试阶段用体验版二维码绑定开发者的微信号即可不影响功能验证。另外避免在小程序名称和宣传语里出现医疗挂号诊疗等字眼改用接种服务健康服务这类中性表达审核通过率会高很多。7. 模拟场景下的系统自测清单像用户一样走一遍流程写完代码不代表系统能投入使用。我习惯在部署上线前用一份自测清单跑一遍完整的用户旅程把系统当做一个真正的用户去操作而不是跳着调用接口。这份清单对你也直接可用7.1 正常流程自测用户首次打开小程序 → 授权登录 → 个人信息页是否自动弹窗提醒完善资料资料提交后是否刷新成功用户能浏览疫苗列表 → 查看不同疫苗的详细介绍和适用人群 → 点击立即预约是否进入排期选择页选择未来三天的排期 → 系统是否展示每个时间段的剩余号源已满的时间段是否置灰不可点击提交预约成功 → 是否出现预约成功弹出层、预约详情是否显示时间和地点 → 微信是否收到订阅消息通知进入我的预约 → 查看待接种列表 → 点击取消预约 → 号源是否释放、状态是否变为已取消模拟医生端核销 → 扫码成功 → 预约状态变为已核销 → 生成接种记录 → 用户端是否显示已完成7.2 异常场景自测同一时间两个用户抢最后一个号源后提交的请求是否被正确拦截是否提示名额已满用户没有完善个人信息就点击预约是否被引导先完善资料用户token过期后发起请求是否跳转登录页而不是白屏管理端删除某一疫苗的排期后用户端已生成的待接种预约如何处理我的策略是强制取消并推送通知避免用户白跑一趟疫苗库存为0时管理端是否还能创建排期必须拦截。7.3 压力自测如果条件允许用JMeter或者简单脚本模拟100个并发用户同时预约同一排期观察接口响应时间和剩余号源是否正确。对毕设来讲在线人数不用多能保证在一分钟内几百个请求不出错就足够了。这一套自测做完系统的可用性基本心里有底了。也可以请身边朋友拿自己的微信号扫描体验版二维码实际走一遍流程——不同人操作习惯不同往往能发现你自己永远想不到的问题。8. 项目回顾踩过的坑和想明白的道理最后聊几个实际操作中比较有代表性的坑希望能帮你少走弯路。第一个坑是报名时库存和预约状态不同步。最初我把预约成功和库存扣减拆成两次数据库操作没有用事务结果有一次预约提交后库存扣减失败用户预约成功但实际没有库存对应医生核销时才发现。后来统一用Spring的Transactional把扣库存和生成预约单包在同一事务里任何一个环节异常都整体回滚问题就再没出现过。第二个坑是微信订阅消息的模板选择和到期策略。刚开始我用的是长期订阅模板以为可以多次推送结果消息发不出去。后来查文档才发现微信把订阅消息分成了一次性订阅和长期订阅两种长期订阅只开放给特定政务医疗类目。对于我们这种普通开发只能老老实实在每次操作时引导用户重新订阅用一次性订阅。理解了限制之后提醒策略就设计成预约成功时订阅接种前一天推送一条消息发挥作用。第三个坑是时间段的容量计算。最开始我把每个时间段的号源数设成固定值比如上午固定放50个号但如果当天医生轮班少、或者疫苗库存只有30支就会有空号或者超出的情况。后来改成由管理员创建排期时手动填号源数并且系统自动校验不能超过疫苗库存和当日接种能力才把这个隐患解决。第四个坑是身份证校验。身份证号是资格校验的关键数据但很多用户输入时容易填错——多一位少一位很难察觉。后来在用户完善资料页面加了本地校验18位、校验位算法并且在提交到后端后用Pattern注解做二次校验把脏数据挡在系统外面。整个项目做完我的体会是这类管理系统真正的难度不在技术本身而在于对业务规则的理解深度。SpringBoot加微信小程序这个组合技术栈成熟、资料多、学习成本低真正让系统有含金量的是疫苗批次管理、资格校验规则、库存联动、消息闭环这些业务细节。如果你准备做类似的课题建议先花一周时间把业务流程彻底吃透画出完整的用户旅程图再动手写代码。业务想清楚了代码只是时间问题业务没想清楚代码写得再漂亮也是空中楼阁。
SpringBoot+微信小程序：疫苗预约管理系统设计与实现
1. 疫苗预约这个场景到底难在哪里做接种预约系统之前我先把线下接种点的真实工作流程捋了一遍。社区接种点每天要做的事情远比想象中繁琐统计各疫苗库存、安排接种台次、通知接种者时间、核对身份信息、记录接种批次、处理爽约和改期一套流程下来全是人工操作。更麻烦的是疫苗这种特殊商品和其他预约场景有本质区别。电影院选座、餐厅排号资源是无限的人到了就消费。疫苗不一样每一支疫苗都有严格的批次管理、冷链存储要求和效期限制一个批次开封后必须在规定时间内用完否则就是损耗。而且不同疫苗的接种间隔要求完全不同新冠疫苗、HPV疫苗、流感疫苗、儿童规划疫苗各自的剂次间隔、适用人群、禁忌症都不一样。这就决定了疫苗预约系统绝不是一个简单的选时间点确认的CRUD它背后至少要处理好四件事库存与排期的联动。接种点按周或者按月设置放号计划每个号源对应某一天的某个时间段但这个时间段能放多少号取决于当天分配到多少支疫苗、有几个接种台、每个台次处理一个接种者需要多久。接种资格的校验。不是谁都可以约任何疫苗。HPV疫苗有年龄限制新冠疫苗有剂次间隔要求儿童疫苗要严格按出生日期计算应种月龄。系统得在用户提交预约时自动完成这部分校验不能等医生现场发现再劝退。爽约和改期处理。线下接种点最头疼的就是爽约率。约了不来疫苗开封了没人打直接浪费。系统要么设计保证金机制要么利用微信消息通知反复提醒要么限制爽约次数总之要把号源利用率提上去。接种记录的闭环。预约完成只是起点接种后的留观记录、接种批次归档、第二针第三针的自动提醒都要在这个系统里形成闭环否则就只是个预约工具称不上管理平台。想清楚这些之后整体方案也就有方向了后端用SpringBoot构建RESTful API小程序端负责用户交互和预约操作管理端做排期、库存和记录管理。下面是完整的落地过程。2. 技术选型的逻辑为什么是SpringBoot加微信小程序2.1 后端框架SpringBoot解决的是开发效率问题选SpringBoot不是因为它流行而是它确实适合这种业务系统。疫苗接种预约管理本质上是一个典型的业务管理系统CRUD多、权限体系明确、需要对接微信生态SpringBoot在这一类项目里几乎是标准解。具体来说SpringBoot在这套系统里承担四层职责接口层对外暴露预约、查询、取消、签到、记录等RESTful接口统一返回格式和异常处理。所有接口都走HTTP JSON协议小程序端直接调用。业务层把预约资格校验、库存扣减、状态流转、消息推送这些核心逻辑隔离在Service层保证Controller只做参数接收和响应封装。这部分是整个系统的重心后面会展开讲。数据层通过MyBatis-Plus操作MySQL数据库利用其内置的CRUD方法减少重复代码复杂查询走自定义SQL。疫苗批次、排期计划、预约单、接种记录都要落库。基础设施整合Redis做分布式锁和热点缓存Quartz或Spring Task做定时任务比如每天凌晨自动关闭过期号源、发送接种提醒这些在SpringBoot里都有非常成熟的 starter 支持。和SSH老框架比SpringBoot最大的优势是约定大于配置——你不用花时间纠结xml配置文件的写法依赖管理由starter自动完成本地开发一个SpringBootApplication启动类就能跑起来。对毕业设计或者中小型项目来说这套组合拳足够高效。2.2 前端载体小程序比H5和App更匹配接种场景疫苗预约的使用场景非常分散用户可能在社区公告栏看到通知可能在家庭群里被转发可能临时接到短信提醒。让用户为了预约专门下载一个App转化率一定很低做H5页面虽然免安装但入口太深需要分享链接才能到达。微信小程序的优势恰好击中这个需求打开微信就能搜到、扫码就能进入、用完即走。而且小程序天然具备微信登录的能力不需要用户重新注册账号——政务民生类场景里能用微信身份直接登录是最省事的方案用户不需要额外设置密码也不会因为忘记密码流失。技术上我选择原生小程序开发不用uni-app或Taro跨端框架。原因是这个项目只需要跑在微信平台没有多端分发诉求原生框架的调试工具和API文档最完整遇到问题最容易搜到解决方案。跨端框架的优势在于一套代码多端运行但代价是框架层可能有坑对毕设或者单人项目来说原生开发其实更稳。2.3 前后端通信RESTful接口约定前后端分离的核心是接口约定。我用的方案是基础路径/api/v1 鉴权方式token登录后由后端签发请求头Authorization携带 返回格式{ code: 200, message: ok, data: {} }不要小看这个统一返回格式前后端联调时90%的沟通成本都浪费在这个接口到底返回什么结构上。提前定义好code的语义200成功、401未登录、403无权限、400参数错误、500服务异常再封装一个通用的ResultT类后端所有接口统一返回这个结构前端在网络请求封装层统一拦截处理效率能提升一大截。小程序的网络请求封装也很简单wx.request包一层就行// utils/request.js const request (url, method, data) { return new Promise((resolve, reject) { wx.request({ url: ${BASE_URL}${url}, method, data, header: { Authorization: wx.getStorageSync(token) || }, success: (res) { if (res.data.code 200) { resolve(res.data.data); } else if (res.data.code 401) { wx.navigateTo({ url: /pages/login/login }); } else { wx.showToast({ title: res.data.message, icon: none }); reject(res.data); } }, fail: reject }); }); };这里有个容易忽略的细节token过期后不能只在控制台打日志一定要统一跳转到登录页否则用户会以为系统卡死了。这个笔者在实际测试中就踩过——明明接口报401页面上没有任何反馈白屏了好几秒体验非常糟糕。3. 核心业务链路的实现排期、预约、核销与提醒3.1 排期生成号源从哪来接种点的排期不是随便填几个日期就完事它要根据疫苗库存和接种能力来算。我在数据库里设计了vaccine_stock疫苗库存表和schedule_plan排期计划表两张核心表vaccine_stock记录每个批次的疫苗名称、库存数量、生产日期、效期、所属接种点。schedule_plan记录某一天某个接种点放出的预约名额关联具体的疫苗批号和可预约数量。当管理员在管理端创建排期时系统自动校验当天该疫苗的可用库存如果排期放号数量大于库存数量直接拦截并提示。这个校验逻辑很简单但非常关键——疫苗是实物放号放多了没法履约放少了浪费资源。实际开发中我还做了一个增强优化每个schedule_plan关联的疫苗批号在用户预约成功后就把对应批号的库存预占掉。也就是说用户下单成功即视为锁定一支疫苗库存表立即扣减。这样管理员在后台看到的库存永远是真实剩余量而不是理论剩余量扣除未核销预约这种绕来绕去的计算方式。排期的时间粒度我建议设成上午/下午/晚上三个时间段而不是精确到具体时刻。原因有二一是接种点现场的节奏很难精确到分钟医生可能因为某个接种者不良反应观察时间稍长而延误按时间段预约容错性更好二是从产品角度看用户对时间粒度的预期不需要那么精确只要知道上午还是下午去就行预约转化率反而更高。3.2 预约提交资格校验的三道关卡预约接口是整个系统最核心的接口也是并发压力最大的接口。一个热门疫苗的号源放出后几十上百人同时点击处理不好就会出现超卖。我的预约流程是三层校验第一层用户身份校验。判断用户是否已登录、是否已完成实名信息登记姓名、身份证、手机号。很多预约系统死在这步——用户点击预约才发现要填一堆资料直接放弃。优化方案是用户首次进入小程序时就引导完善个人信息后续预约无需重复填写。第二层业务资格校验。根据用户性别、出生日期、历史接种记录判断是否符合该疫苗的接种条件。比如HPV九价疫苗要求女性且在适龄范围内新冠疫苗第二针要求距离第一针超过21天这类规则全部做成可配置的校验策略不同疫苗挂不同的校验器。第三层库存与并发校验。先查缓存再查数据库确认该时间段还有剩余号源然后利用Redis分布式锁防止并发超卖// 伪代码预约提交核心逻辑 public void createAppointment(AppointmentRequest request) { // 1. 业务资格校验 validateEligibility(request.getUserId(), request.getVaccineId()); // 2. 分布式锁锁粒度排期计划ID String lockKey appointment:lock: request.getSchedulePlanId(); boolean locked redisLock.tryLock(lockKey, 5, TimeUnit.SECONDS); if (!locked) { throw new BusinessException(当前预约人数过多请稍后重试); } try { // 3. 检查剩余名额 int remain schedulePlanMapper.getRemainCount(request.getSchedulePlanId()); if (remain 0) { throw new BusinessException(该时间段名额已满); } // 4. 扣减库存、生成预约单 schedulePlanMapper.decreaseRemainCount(request.getSchedulePlanId()); appointmentMapper.insert(buildAppointment(request)); // 5. 发送微信订阅消息提醒 wxMessageService.sendAppointmentSuccessNotice(request); } finally { redisLock.unlock(lockKey); } }分布式锁在这个场景里是必须的。有人可能觉得用数据库行锁或者乐观锁也能做但实际并发量一上来数据库锁会导致接口响应时间急剧膨胀。当然如果只是毕业设计或者演示用的Demo用数据库的UPDATE ... WHERE remain_count 0也能扛住原理都是避免超卖只是性能和体验的差别。还有一点容易忽略预约成功后一定要异步发送微信订阅消息不能放在主流程里同步执行。微信订阅消息的发送接口有时会有几秒延迟同步发送会把预约操作的响应时间拖长用户觉得卡顿。用Spring的Async注解丢到线程池里处理主流程只负责保存数据和返回结果。3.3 核销签到闭环保关键的一环用户按照预约时间到接种点后医护人员需要核验预约信息并完成签到。小程序端提供一个我的预约页面展示预约二维码管理端用扫码枪或者手机摄像头扫码识别预约单号后自动完成核销。核销的核心逻辑是状态流转。预约单的状态我定义成五个WAIT_APPOINT待预约→ BOOKED已预约→ CHECKED_IN已核销→ COMPLETED已完成 ↘ CANCELLED已取消核销操作就是把BOOKED状态改成CHECKED_IN同时生成一条接种记录关联疫苗批次、接种部位、接种医生等信息。这一步做完管理员在后台就能看到今日接种数据包括已预约数、已核销数、未到数爽约率一目了然。实际开发中核销部分有一个容易踩的坑二维码内容不能直接填预约单ID否则被人恶意遍历ID就能伪造预约。我的做法是生成一个带签名的随机串比如MD5(预约单号 随机盐)扫码后后端验证签名有效才放行。虽然小程序端做了登录鉴权但管理端扫码入口是公开页面这种安全设计能挡掉大部分低级攻击。3.4 智能提醒让爽约率降下来的实用技巧接种提醒是业务里最简单但用户感知最强的功能。预约成功通知、接种前一天提醒、接种后留观提醒、第二针到期提醒这几个节点做好用户对系统的好感度会明显提升。技术实现用的是微信订阅消息核心是wx.requestSubscribeMessage接口。注意这个接口有个一次性订阅的特性——用户每次点击授权只能接收一次消息推送想让用户持续接收提醒就得在每次关键操作时都引导用户重新订阅。实际操作中的经验是把订阅请求放在用户完成预约的瞬间弹窗因为这时候用户的期望值最高完成预约后自然希望收到后续提醒授权通过率最高。如果单独为订阅做一个页面让用户主动勾选通过率通常很差。提醒任务用定时任务实现每天固定时间扫描预约单表找出明天有预约的订单批量发送订阅消息。这里有个性能小优化不要一条一条发微信订阅消息接口支持批量通过openid列表发送一次可以处理几千个用户。4. 数据模型设计关键表和字段背后的业务含义数据模型是项目的根基设计不好后面改起来非常痛苦。我把这套系统的核心表拆开讲一遍每张表的设计逻辑都对应前面提到的业务需求。4.1 核心数据表用户表userid, openid(微信唯一标识), nickname, avatar, id_card(身份证号), phone, gender, birth_date, address, create_time, update_time身份证号和出生日期是接种资格校验的基础数据。需要注意身份证、手机号属于敏感信息数据库里要么加密存储要么至少做脱敏展示接口返回给前端时不能直接全量返回身份证号。疫苗表vaccineid, name(疫苗名称), type(疫苗类型新冠/HPV/流感/儿童规划疫苗), manufacturer(生产厂家), description, interval_days(剂次间隔天数), max_doses(最大接种剂次), applicable_scope(适用人群范围), statusinterval_days和max_doses这两个字段是资格校验规则的数据来源。比如新冠疫苗interval_days21用户在预约第二针时系统自动计算第一针接种日期加21天后是否小于等于当前日期不满足就直接拒绝。疫苗库存表vaccine_stockid, vaccine_id, batch_no(批号), stock_count(库存数量), production_date, expiry_date, site_id(所属接种点), status批号和效期管理是我特别强调的。社区卫生服务中心检查时必查疫苗批号追溯每支疫苗从出厂到接种给谁必须能完整追踪所以vaccine_stock必须保留batch_no字段接种记录也必须关联到批号。排期计划表schedule_planid, vaccine_id, stock_id, site_id, plan_date(放号日期), time_slot(时间段上午/下午/晚上), total_count(总号源), remain_count(剩余号源), statusremain_count是预约并发控制的关键字段所有预约操作都围绕它做扣减。这里我做了缓存优化热门疫苗的排期信息放在Redis里键设计为schedule:info:{planId}值存剩余号源数量预约时先查Redis再落库显著降低数据库压力。预约表appointmentid, user_id, vaccine_id, schedule_plan_id, appointment_no(预约单号), status(BOOKED/CHECKED_IN/CANCELLED/COMPLETED), appointment_date, time_slot, check_in_time, cancel_reason, create_time预约表是整个业务流的主线所有状态流转都围绕它进行。appointment_no生成规则我用了时间戳加随机数的组合保证唯一且不可预测。接种记录表vaccination_recordid, user_id, vaccine_id, stock_id, doctor_id, vaccination_date, dose_number(第几剂), injection_site(接种部位), batch_no(疫苗批号), adverse_reaction(不良反应记录), status接种记录是疾控中心要求保留的档案数据也是后续资格校验的判据。用户端展示我的接种记录查询接口就从这张表取数。4.2 设计取舍的思考数据模型设计过程中有一个值得分享的取舍预约表和时间段的解耦。最初我的设计是预约表直接存appointment_time精确到分钟后来和接种点医生聊过之后才发现实际工作中预约时间根本无法精确到分钟预约9:00的用户可能9:30才到前面的号因为各种原因顺延很正常。改成时间段模型后用户看到的是7月25日上午医生端看到的是当天上午的预约名单按到达顺序核销就行。这个改动看似简单但把整个系统的可用性提升了不止一个档次——从那以后就没有出现过预约超时未到系统自动取消这种逻辑问题。另一个取舍是是否引入site_id接种点维度。如果你做的是一个社区级别的平台只有单个接种点可以不用这个字段但如果你想把这个项目扩展成区域级平台一个区多个接种点从第一天就保留site_id字段后续扩展会容易很多。我的建议是至少预留这个字段不要为了省事把所有表混在一起后面想加维度还得动表结构。5. 消息通信与权限控制小程序端容易忽略的两个细节5.1 登录鉴权与token管理小程序登录流程遵循微信官方标准wx.login获得code后传给后端后端调用code2Session接口换取openid然后签发自定义token返回给小程序。token存到wx.setStorageSync里每次请求带上。这个流程本身不复杂但有一个细节容易被新手忽略code2Session接口的网络耗时。微信的接口调用在国内网络环境下通常100-300毫秒如果每次进入小程序都先走一遍这个流程再加载页面用户会觉得加载很慢。优化方案是openid获取成功后缓存在Redis里设置过期时间比如7天下次用户进入小程序时先检查本地token是否有效有效就跳过登录流程直接进入首页。只有token失效时才重新走wx.login换取新code。具体的完整登录流程我在实现时分了三步首次进入调用wx.login获取code → 后端换openid → 查询用户表是否存在不存在则创建默认用户 →签发token。信息完善用户进入个人信息页补充身份证、出生日期、手机号等必填信息在需要展开接口层时直接声明PreAuthorize或自定义拦截器校验用户权限角色。管理端接口统一加上管理员角色校验普通用户token访问管理接口直接拒绝。后续访问小程序请求头带上token后端通过拦截器解析token拿到用户身份不再每次都查数据库。5.2 用户角色与权限设计这套系统天然有两种角色普通用户接种者和管理员接种点医护人员。我用Spring Security加上JWT实现角色权限控制。后端实现方式不复杂继承OncePerRequestFilter写一个JWT过滤器在doFilterInternal里解析请求头的token拿到用户ID和角色信息后注入Spring Security的上下文public class JwtAuthenticationFilter extends OncePerRequestFilter { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { String token request.getHeader(Authorization); if (StringUtils.hasText(token) token.startsWith(Bearer )) { // 解析token获取用户ID和角色 Claims claims JwtUtil.parseToken(token.replace(Bearer , )); // 构造Authentication对象存入SecurityContext // ... } filterChain.doFilter(request, response); } }管理端接口全部挂在/api/v1/admin/**路径下Spring Security配置规则时对该路径设置hasRole(ADMIN)普通用户即使构造请求也访问不到管理端接口。小程序端的权限控制主要靠页面跳转限制和按钮隐藏。管理员登录小程序后通过一个切换身份按钮进入管理页。管理页的入口仅在用户角色为ADMIN时显示避免普通用户误入管理页面。6. 部署与数据安全上线前必须处理的三件事6.1 线上环境的应用部署方案项目开发完成后部署方案我建议采用单机加Docker Compose足够应对中小型社区接种点的访问量。如果你只是做毕业设计可以简化到在服务器上直接跑Java进程加MySQL不需要上Docker编排。一个参考的部署结构如下后端服务打包成Jar包运行推荐用nohup java -jar或者注册成systemd服务监听8080端口。数据库MySQL 8.0单独服务器或者本机都可以注意开启远程连接权限并修改默认密码策略。Redis负责分布式锁和缓存独立运行设置访问密码。Nginx做反向代理把/api/路径转发到后端服务同时托管小程序的静态资源和管理员H5页面。生产环境一个非常关键的点是配置文件不能把密码写死。至少要区分application-dev.yml和application-prod.yml数据库密码、Redis密码、小程序AppSecret等在本地和线上分别配置。SpringBoot的ConfigurationProperties绑定方式配合环境变量注入是我比较推荐的做法# application-prod.yml spring: datasource: password: ${DB_PASSWORD} redis: password: ${REDIS_PASSWORD} wechat: appid: ${WECHAT_APPID} secret: ${WECHAT_SECRET}启动时通过--spring.profiles.activeprod指定环境机密信息全部来自环境变量而不是写死在yml里。6.2 数据脱敏与隐私保护疫苗接种系统涉及大量个人敏感信息姓名、身份证号、手机号、健康记录。上线前不管别人有没有要求以下几条必须做到日志脱敏Controller层和Service层不要打印身份证号、手机号明文日志只打印掩码版本如110***********1234。之前我调试时随手打了整个用户对象后来回看日志冷汗直冒。接口脱敏返回给前端的数据中身份证号、手机号、地址等字段要么不返回要么只返回部分手机号中间四位打码。数据库查询时可以用SQL函数处理或者后端序列化时统一脱敏。授权最小化管理端账号按角色分配权限值班医生账号只允许查看当日预约和接种记录不具备修改疫苗库存和删除预约的权限。数据安全是合规底线不是有空再补的功能。6.3 微信小程序审核注意事项小程序上线前需要通过微信审核医疗健康类目对资质要求非常严格。如果你是以个人开发者身份注册小程序类目只能选工具或者生活服务一旦涉及疫苗、医疗相关内容审核大概率会被驳回。实际操作中的经验是先以个人身份注册开发版体验等流程完整跑通后再提交给有医疗资质的机构主体去重新注册发布。测试阶段用体验版二维码绑定开发者的微信号即可不影响功能验证。另外避免在小程序名称和宣传语里出现医疗挂号诊疗等字眼改用接种服务健康服务这类中性表达审核通过率会高很多。7. 模拟场景下的系统自测清单像用户一样走一遍流程写完代码不代表系统能投入使用。我习惯在部署上线前用一份自测清单跑一遍完整的用户旅程把系统当做一个真正的用户去操作而不是跳着调用接口。这份清单对你也直接可用7.1 正常流程自测用户首次打开小程序 → 授权登录 → 个人信息页是否自动弹窗提醒完善资料资料提交后是否刷新成功用户能浏览疫苗列表 → 查看不同疫苗的详细介绍和适用人群 → 点击立即预约是否进入排期选择页选择未来三天的排期 → 系统是否展示每个时间段的剩余号源已满的时间段是否置灰不可点击提交预约成功 → 是否出现预约成功弹出层、预约详情是否显示时间和地点 → 微信是否收到订阅消息通知进入我的预约 → 查看待接种列表 → 点击取消预约 → 号源是否释放、状态是否变为已取消模拟医生端核销 → 扫码成功 → 预约状态变为已核销 → 生成接种记录 → 用户端是否显示已完成7.2 异常场景自测同一时间两个用户抢最后一个号源后提交的请求是否被正确拦截是否提示名额已满用户没有完善个人信息就点击预约是否被引导先完善资料用户token过期后发起请求是否跳转登录页而不是白屏管理端删除某一疫苗的排期后用户端已生成的待接种预约如何处理我的策略是强制取消并推送通知避免用户白跑一趟疫苗库存为0时管理端是否还能创建排期必须拦截。7.3 压力自测如果条件允许用JMeter或者简单脚本模拟100个并发用户同时预约同一排期观察接口响应时间和剩余号源是否正确。对毕设来讲在线人数不用多能保证在一分钟内几百个请求不出错就足够了。这一套自测做完系统的可用性基本心里有底了。也可以请身边朋友拿自己的微信号扫描体验版二维码实际走一遍流程——不同人操作习惯不同往往能发现你自己永远想不到的问题。8. 项目回顾踩过的坑和想明白的道理最后聊几个实际操作中比较有代表性的坑希望能帮你少走弯路。第一个坑是报名时库存和预约状态不同步。最初我把预约成功和库存扣减拆成两次数据库操作没有用事务结果有一次预约提交后库存扣减失败用户预约成功但实际没有库存对应医生核销时才发现。后来统一用Spring的Transactional把扣库存和生成预约单包在同一事务里任何一个环节异常都整体回滚问题就再没出现过。第二个坑是微信订阅消息的模板选择和到期策略。刚开始我用的是长期订阅模板以为可以多次推送结果消息发不出去。后来查文档才发现微信把订阅消息分成了一次性订阅和长期订阅两种长期订阅只开放给特定政务医疗类目。对于我们这种普通开发只能老老实实在每次操作时引导用户重新订阅用一次性订阅。理解了限制之后提醒策略就设计成预约成功时订阅接种前一天推送一条消息发挥作用。第三个坑是时间段的容量计算。最开始我把每个时间段的号源数设成固定值比如上午固定放50个号但如果当天医生轮班少、或者疫苗库存只有30支就会有空号或者超出的情况。后来改成由管理员创建排期时手动填号源数并且系统自动校验不能超过疫苗库存和当日接种能力才把这个隐患解决。第四个坑是身份证校验。身份证号是资格校验的关键数据但很多用户输入时容易填错——多一位少一位很难察觉。后来在用户完善资料页面加了本地校验18位、校验位算法并且在提交到后端后用Pattern注解做二次校验把脏数据挡在系统外面。整个项目做完我的体会是这类管理系统真正的难度不在技术本身而在于对业务规则的理解深度。SpringBoot加微信小程序这个组合技术栈成熟、资料多、学习成本低真正让系统有含金量的是疫苗批次管理、资格校验规则、库存联动、消息闭环这些业务细节。如果你准备做类似的课题建议先花一周时间把业务流程彻底吃透画出完整的用户旅程图再动手写代码。业务想清楚了代码只是时间问题业务没想清楚代码写得再漂亮也是空中楼阁。
