这几年只要带“SpringBoot 微信小程序”字样的题目在高校毕设里几乎快被做烂了。但被做烂不等于好做恰恰相反我自己带过几个学生选类似的题目发现绝大多数人都在预约库存、登录态、小程序联调这些环节翻车。疫苗预约这个业务表面看就是一个普通的信息管理系统但真正做起来要处理用户端、管理端、接种点端三个角色还要考虑同一时段疫苗库存的并发扣减、微信登录态怎么安全保持、小程序上线时域名和HTTPS的校验规则哪一环没想明白都会卡住好几天。这篇内容就把这套“SpringBoot 微信小程序”的疫苗预约系统整体拆开讲一遍从项目功能划分、技术选型思路到后端核心接口怎么写、数据库表怎么设计再讲小程序前端的请求封装和预约页面实现最后把联调和上线阶段最容易踩的坑总结成清单。不管你是正在做这个毕设题目还是单纯想用一个小程序项目练手全栈开发这篇都可以当作一份完整参考。1. 项目整体设计与功能拆解1.1 这套系统到底要解决什么问题疫苗接种预约的核心业务逻辑并不复杂用户打开小程序看到有哪些疫苗、哪些接种点、还有多少号源选择一个合适的时间段提交预约然后按时间到现场接种工作人员核销预约记录。真正复杂的是这个流程里的状态变化和边界条件。从业务上拆分这套系统需要覆盖三条线用户线、预约线、管理线。用户线上用户要能浏览疫苗列表、查看接种点信息、注册登录、提交预约、查看自己的预约记录、取消预约预约线上系统要维护某个接种点在某个时间段的号源库存用户提交预约时实时扣减库存到了时间点要有“待接种、已完成、已取消”的状态流转管理线上管理员可以维护疫苗数据、发布通知公告、查看预约统计接种点工作人员需要核销用户的预约码。三个角色如果都要做后台管理的量会比较大。很多学生选这个题其实只做了用户端小程序加一个简单的后台管理页面答辩时的说法是“管理员可登录后台管理系统维护数据”。我个人建议是如果时间有限小程序端优先做扎实后台管理可以用SpringBoot自带的模板页面做基础增删改查没必要硬撑一个Vue后台系统。把用户端的主流程跑顺比堆一堆半成品功能更能拿分。1.2 技术选型为什么要这样搭配从搜索引擎里那些热搜词也能看出来大家对这个题目的关注点基本集中在SpringBoot和微信小程序这两大块。我见过不少人是第一次接触这套组合所以在选型上不用搞得太花哨但每选一个东西都要知道它负责解决什么问题。后端用SpringBoot 2.x而不是3.x这是很多新手没注意的坑。SpringBoot 3要求JDK 17以上而很多学校电脑上装的还是JDK 8如果整机环境没升级一开项目就是各种兼容报错特别打击信心。SpringBoot 2.7.x配JDK 8是目前最稳的组合。数据库用MySQL这个没什么好说的生态成熟、教程多、出问题好排查。ORM层我推荐MyBatis-Plus而不是原生MyBatis原因很简单单表CRUD不用写XML内置的分页插件和条件构造器能省下大量时间。疫苗预约这个项目里疫苗列表分页、预约记录按条件查询是高频操作用MyBatis-Plus几乎不需要手写SQL。登录态这块微信小程序有自己的wx.login机制不能直接用传统的用户名密码登录而是要通过code换session_key和openid。为了不让小程序每次请求都携带openid裸奔后端还要做一层Token签发。我用的方案是JWT服务端无状态、不需要存session小程序端把token存到storage里每次请求在header里带上后端用拦截器统一校验。缓存和分布式锁这块如果有余力可以引入Redis。疫苗预约最典型的高危场景是同一时段、同一接种点的疫苗库存被并发扣减用一个Redis分布式锁或者数据库乐观锁就能保证不超卖。如果不想引入Redis光靠数据库的乐观锁也能实现后面核心模块里我会详细说。1.3 数据库设计与核心表结构数据库表设计是答辩时老师最喜欢深挖的部分也是整个项目的地基。表设计如果一开始没想清楚后面写请求接口的时候就会频繁返工。我建议疫苗预约系统至少要包含下面这几张核心表。用户表usersid、openid微信唯一标识、nickname、avatar、phone、gender、create_time、update_time。openid必须加唯一索引这是用户身份的根登录逻辑全靠它来区分用户。phone字段建议一开始就预留很多系统后期要加“接种提醒短信”没有手机号就接不上。疫苗信息表vaccineid、name如“新型冠状病毒灭活疫苗”、manufacturer生产厂家、type疫苗类型、dosage接种剂次、description、status上下架状态、create_time。要注意疫苗的批次信息或者价格信息如果想做库存预警还可以加一个stock_warning字段。接种点信息表siteid、name、address、phone、work_start_time、work_end_time、daily_limit每日最大预约人数。预约记录表appointment这是全项目最核心的表。id、user_id、vaccine_id、site_id、appointment_date预约日期、time_slot时段比如“09:00-10:00”、status1待接种/2已完成/3已取消/4已过期、appointment_code预约码、remark、create_time。这个表在设计时一定要考虑查询场景user_id用于用户查看自己的记录site_id和appointment_date、time_slot用于接种点统计当日各时段预约人数。公告表noticeid、title、content、create_time。字段设计上有一个很重要的经验时间字段统一用datetime不要混用timestamp和date否则查询日期范围的时候边界容易出问题。预约日期这种字段看起来只需要date类型但实际在Java实体里映射时处理不当会导致前端展示的时间比预期少8个小时原因就是时区转换。我的做法是数据库统一datetimeJava端用LocalDate或LocalDateTime接收JSON序列化时指定格式后面章节里会再提到。2. 后端核心模块设计与关键实现2.1 微信登录链路从code换token的完整过程微信小程序的登录和传统网页登录不一样。用户在小程序端点击授权之后前端调用wx.login拿到一个临时凭证code后端拿这个code去微信的接口换openid和session_key。这个code有效期只有5分钟而且只能用一次拿到之后必须马上处理。我用一张流程图来说清楚整个链路小程序端wx.login获取code → 后端接收code → 后端调用微信接口https://api.weixin.qq.com/sns/jscode2session → 微信返回openid和session_key → 后端用openid查数据库 → 如果不存在就注册新用户 → 后端生成JWT返回给小程序 → 小程序把token存到storage → 后续请求在header里带token。这里有一个关键点很多人搞不懂为什么不直接把openid返回给小程序还要再签发一个JWT原因有两个。一是openid是用户在微信体系里的唯一标识相当于用户在这个小程序里的身份证号如果每次请求都明文传输一旦被截获就可以伪造用户身份二是JWT带了过期时间和服务端校验信息后端可以通过拦截器统一控制接口访问权限这样管理端接口和小程序端接口可以共用一套鉴权机制。核心代码可以这样写。先建一个WxAuthService负责调用微信接口Service public class WxAuthService { Value(${wechat.appid}) private String appid; Value(${wechat.secret}) private String secret; public String getOpenid(String code) { String url https://api.weixin.qq.com/sns/jscode2session?appid appid secret secret js_code code grant_typeauthorization_code; // 发送HTTP请求解析返回的openid // 微信返回格式: {openid:xxx,session_key:xxx} // 注意错误处理: 如果code无效或过期返回errcode return openid; } }这里要注意请求微信接口时要设置超时时间别让接口调用卡死。我用的是RestTemplate设置3秒连接超时和3秒读取超时实测够用了。然后写登录ControllerPostMapping(/login) public Result login(RequestBody LoginRequest request) { String openid wxAuthService.getOpenid(request.getCode()); User user userService.findByOpenid(openid); if (user null) { user new User(); user.setOpenid(openid); user.setNickname(微信用户 openid.substring(openid.length() - 6)); userService.save(user); } String token JwtUtil.generateToken(user.getId(), user.getOpenid()); return Result.success(new LoginResponse(token, user)); }2.2 预约接口与防超卖设计预约是疫苗系统的核心接口也是最容易出并发问题的接口。打个比方某接种点某天的某个时段只剩最后一针号源两个用户同时点了预约按钮如果没有并发控制两个人都能成功提交数据库里出现两条预约记录但库存只减了两次看起来数据是正常的实际上超卖了。解决思路有三种第一种是synchronized加锁但这只能保证单台服务器内线程安全部署多实例就不生效而且锁的范围很难控制第二种是数据库乐观锁通过版本号或者库存大于0的条件来更新第三种是Redis分布式锁性能最好但要额外引入Redis依赖。对于毕设项目我推荐用数据库乐观锁理由很直接不引入额外中间件逻辑简单好讲解答辩时能说清楚。方案是这样的预约记录表里不需要存库存数量库存信息放在接种点的时段库存表或者直接在疫苗库存表里维护一个remaining字段。用户在提交预约时先查询剩余库存如果大于0则执行下面这条更新语句UPDATE vaccine_stock SET remaining remaining - 1 WHERE vaccine_id ? AND site_id ? AND time_slot ? AND remaining 0;这条SQL的精髓在于最后的remaining 0条件。如果这条更新语句影响行数为1说明扣减成功可以继续插入预约记录如果影响行数为0说明当前时段库存已经被抢完了直接返回“号源不足”。更新和插入必须放在同一个事务里保证要么都成功要么都不成功。好的这里给出一个完整的预约流程代码Transactional(rollbackFor Exception.class) public AppointmentResult createAppointment(AppointmentRequest request) { // 1. 检查用户是否已存在未完成的预约 Long count appointmentMapper.selectCount( new LambdaQueryWrapperAppointment() .eq(Appointment::getUserId, request.getUserId()) .eq(Appointment::getStatus, 1) .eq(Appointment::getAppointmentDate, request.getAppointmentDate())); if (count 0) { return AppointmentResult.error(您已有待接种的预约记录请勿重复预约); } // 2. 乐观锁扣减库存 int rows vaccineStockMapper.deductStock( request.getVaccineId(), request.getSiteId(), request.getTimeSlot()); if (rows 0) { return AppointmentResult.error(该时段号源已被约满请选择其他时段); } // 3. 生成预约码并插入预约记录 Appointment appointment new Appointment(); appointment.setUserId(request.getUserId()); appointment.setVaccineId(request.getVaccineId()); appointment.setSiteId(request.getSiteId()); appointment.setAppointmentDate(request.getAppointmentDate()); appointment.setTimeSlot(request.getTimeSlot()); appointment.setStatus(1); appointment.setAppointmentCode(generateCode()); appointmentMapper.insert(appointment); return AppointmentResult.success(appointment); }为什么用户已经存在待接种记录时要拦截这是业务规则问题也是实际项目里很容易漏掉的一个点。疫苗预约通常不允许同一人同一天在不同接种点重复预约否则会造成号源浪费。我见过很多系统这张表上没有唯一约束用户连续点击提交按钮就生成了多条预约记录这是非常严重的逻辑漏洞。另外预约码的设计也要注意。不要用自增ID做预约码因为用户通过预约码可以反推出平台单量而且自增ID容易被遍历存在数据泄露风险。我采用的方式是时间戳加随机数生成比如202501101030123456之类的格式同时加上一个唯一索引生成时如果有冲突就重新生成。2.3 接口权限校验与安全加固预约、查看记录、取消预约这些接口必须是登录后才能访问的否则任何人带一个user_id参数就能查到别人的预约记录。权限校验我用的是拦截器加自定义注解的方式。JwtInterceptor拦截所有以/api/开头的请求从请求头的Authorization字段取出token解析成功后把userId存入ThreadLocal方便Controller直接取用。对于登录、获取疫苗列表这种公开接口在方法上标注PassToken注解跳过拦截。管理端接口用RequireAdmin注解校验当前用户是否有管理权限。代码结构大致是这样public class JwtInterceptor implements HandlerInterceptor { public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { if (handler instanceof HandlerMethod ((HandlerMethod) handler).hasMethodAnnotation(PassToken.class)) { return true; } String token request.getHeader(Authorization); if (StringUtils.isBlank(token) || !JwtUtil.verify(token)) { // 返回401状态码前端根据状态码跳转登录页 response.setStatus(401); return false; } UserContext.set(JwtUtil.getUserId(token)); return true; } }安全这一块很多学生完全没概念但我在这两年的项目评审里看到出了很多实际案例。热搜词里有个“springboot heapdump 敏感信息泄露漏洞”这就是真实发生过的安全事故。如果项目创建时引入了Spring Boot Actuator并且没有限制端点暴露攻击者访问/actuator/heapdump就能把JVM堆内存下载下来里面很可能包含数据库密码、密钥这些敏感信息。经验是生产环境用配置management.endpoints.web.exposure.includehealth,info限制暴露端点如果压根用不到Actuator的功能直接排除这个依赖更干净。还有一点很多小程序的反编译工具能直接把前端的代码抠出来看。前端代码里绝对不能写AppSecret这类微信平台密钥也不能在后端把所有数据明文返回给前端之后再在前端做权限控制。真正安全的做法是所有权限校验都在后端完成前端只负责展示后端返回的数据。3. 小程序前端关键实现与踩坑3.1 网络请求封装与登录态管理小程序端最基础的封装就是wx.request。我见过很多新手写代码每个页面都直接复制wx.request参数写死、没有错误处理、没有统一的loading提示代码又臭又长。正确的做法是把请求封装成一个公共模块所有页面统一调用。封装时要考虑这几点请求地址统一从配置文件里读取不要写死在代码里这样切换正式环境和测试环境时只需要改一个地方请求发起时自动在header里带上token不用每个页面手动加收到401状态码时统一跳转登录页并清除本地storage请求开始时显示一个可控制的loading避免每个接口都弹出“加载中”的提示。我常用的封装代码精简之后如下const request (url, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: ${config.baseUrl}${url}, method, data, header: { Content-Type: application/json, Authorization: wx.getStorageSync(token) }, success: (res) { if (res.statusCode 200) { resolve(res.data); } else if (res.statusCode 401) { wx.removeStorageSync(token); wx.navigateTo({ url: /pages/login/login }); reject(new Error(登录已过期)); } else { wx.showToast({ title: res.data.message || 请求失败, icon: none }); reject(new Error(res.data.message)); } }, fail: (err) { wx.showToast({ title: 网络异常请检查网络连接, icon: none }); reject(err); } }); }); }; module.exports { request };登录态管理的流程是app.js里在onLaunch时调用wx.login获取code然后请求后端/login接口拿到token和userInfo之后存到storage里。这里有一个体验优化点如果每次冷启动都调一次wx.login用户会感觉小程序很慢。我后面做优化时先检查storage里有没有token有token就直接进首页等token真正过期再去重新登录这样启动速度会明显提升。3.2 预约页面的日期选择与时段展示疫苗预约首页通常包含疫苗列表、接种点选择、日期选择、时段选择和剩余号源展示。日期和时段选择是小程序页面里最容易出bug的地方。日期选择如果直接用picker组件的modedate要注意两个问题第一date选择器返回的日期是字符串“YYYY-MM-DD”格式如果直接把字符串传给后端去匹配datetime字段会查不出数据。我当时就在这块卡了一天后来才想到日期字段在库里是datetime查询时必须用DATE()函数包裹或者传“2025-01-10 00:00:00”这种完整格式。第二时段选择要跟实际业务结合。不能全部时段都让用户自由选而要根据当前时间禁用已经过去的时段。比如现在是上午11点那么“09:00-10:00”这个时段就不能再选了。每个时段的剩余号源数量也要实时展示出来不然用户选了一个已被约满的时段提交时才提示失败体验很差。我处理的方式是页面加载时调用后端的时段查询接口后端把该接种点当日所有时段的剩余号源返回来前端做一个简单的二维数组映射时段和剩余数量一一对应。用户选择时段后按钮上直接显示“剩余X人份”如果剩余数量为0就置灰不可点击。这个小细节在演示时很加分能让老师直观感受到你有考虑业务完整度。3.3 小程序启动体验与加载页优化热搜词里有一个“修改刚进入的加载页面”这其实是问小程序启动时底部的loading状态怎么自定义。微信小程序在冷启动时默认会在屏幕上方显示加载loading状态这个loading是由框架控制的没有办法完全去掉但可以通过提升首屏渲染速度来减少用户等待。加速首屏有几个手段第一把首页的网络请求提前在onLoad里马上发起请求不要在onReady之后才发第二用骨架屏替代转圈loading在数据返回前先渲染一个大致布局的占位让用户感觉页面已经加载出来了第三对疫苗列表数据做缓存第二次进入时先展示缓存数据再去后台请求最新数据。后面我把首页改成了“本地缓存即时展示 后台静默更新”的方案启动速度从原来的2秒左右降到了1秒内。具体实现是首页onLoad先读取storage里的疫苗列表缓存如果存在就直接渲染然后同时发起网络请求拿到新数据后视图更新并覆盖缓存。这个优化思路在小程序性能指南里是官方推荐的做法但真正去落地的人不多。4. 联调、部署与真机测试4.1 本地联调让小程序访问本地后端开发阶段在微信开发者工具里跑小程序最烦的一个问题就是本地后端接口的访问权限。微信开发者工具默认要求请求的地址必须配置在request合法域名里但你本地开发哪来的域名这个时候有两条路可以走。第一条路在微信开发者工具的“详情”设置里勾选“不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书”。这个选项只对本地开发工具有效预览和真机调试时不一定生效。勾选之后你的小程序就能直接请求http://localhost:8080了。第二条路真机调试时手机不能访问你电脑上的localhost必须换成局域网IP。比如你的电脑IP是192.168.1.100后端启动时监听0.0.0.0手机访问的服务地址就写http://192.168.1.100:8080。这里有个前提是手机和电脑必须在同一个局域网内而且Windows防火墙要允许Java进程通过否则请求会一直超时。我还遇到过一种情况勾选了不校验域名之后模拟器里能正常请求但真机预览时又不行了。这是因为真机预览走的是微信的request合法域名校验规则开发者工具里的设置不影响真机。所以如果想真机调试还得先把后端的接口地址配置到request合法域名里或者在小程序后台的开发管理里把当前微信号加为体验成员通过体验版去访问。4.2 上线前必须处理的配置真正要把小程序提交审核上线有几个硬性门槛必须提前准备否则审核很容易被打回。我整理了一个清单request合法域名必须是HTTPS协议的而且证书要有效。这意味着后端接口不能只跑在http上需要一台带HTTPS证书的服务器常见的方案是用Nginx反向代理后端并配置SSL证书。就算把SpringBoot的容器换成Tomcat并配置HTTPS前端域名校验通过的概率也更高但我还是建议用Nginx因为配置证书、处理跨域、做请求转发都更灵活。ICP备案也是绕不开的。微信小程序要求所有域名都完成ICP备案如果用的是境外服务器备案基本无望建议直接选择国内云厂商的服务器。另外个人主体的小程序在某些服务类目上可能会受限疫苗预约这种涉及医疗健康的类目个人主体基本不能上线通常需要企业主体或者政府机构主体来提交。这一点在选题阶段就要想清楚如果只是毕业设计演示用开发者工具模拟器跑通功能就够了如果真有上线需求主体资质问题是最容易被忽略的坎。部署后端时数据库连接配置里必须加上serverTimezoneAsia/Shanghai否则服务器和本地数据相差8小时预约记录的时间展示会错乱。我遇到过项目部署到服务器后用户看到的预约时间比实际时间晚了8小时的诡异情况排查半天发现是MySQL连接串没有指定时区最后加了一个参数就解决了。4.3 抓包调试小程序接口排查的必备技能小程序前端报错时光靠console.log往往看不出问题在哪这时候需要抓包工具来看真实请求和响应。我用的比较多的方案是Charles它可以在电脑端开一个代理手机的WiFi代理指向电脑然后所有请求都会被拦截下来。公众号后台配置方面如果小程序正式环境需要发送请求还必须在小程序管理后台把合法域名加到request合法域名里。域名校验规则挺严格的不支持IP地址、不支持端口号、必须HTTPS所以开发环境和生产环境的接口地址要分开配置否则频繁切换很麻烦。抓包的另一个用途是看微信登录接口的返回。很多人code换openid失败不抓包永远不知道微信返回的具体错误信息。常见的有invalid code、appid and secret不匹配、接口调用频率超限这几种每种对应的排查方向都不一样。有了抓包数据自己就能定位一大半问题。5. 常见问题排查与避坑清单做这类前后端分离的小程序项目问题往往不是出在某个单独环节而是出在环境、配置、数据格式这些边缘地带。我把遇到过的问题整理成一张速查表方便大家遇到类似问题时直接对照。问题现象常见原因解决思路小程序请求后端超时未勾选不校验域名真机访问了localhost防火墙拦截开发者工具勾选免域名校验真机改用局域网IP关闭防火墙测试登录时微信返回invalid codecode二次使用code过期appid或secret配置错误code只能使用一次每次点击登录重新wx.login核对后台配置参数token校验失败导致频繁跳登录前后端密钥不一致token过期时间太短本地storage被清理统一JWT密钥配置把过期时间设到7天排查storage写入时机预约时间显示差8小时MySQL连接串没有serverTimezone参数URL末尾加serverTimezoneAsia/Shanghai预约并发导致超卖没有加乐观锁或分布式锁使用remaining 0的条件更新语句配合事务请求返回403后端跨域配置缺失编写WebMvcConfigurer配置跨域策略上传到服务器后接口404Nginx配置的location路径和后端Controller路径不匹配检查Nginx转发规则确保路径正确小程序审核被拒服务类目不符隐私政策不完善缺少拍摄权限说明对照微信审核规范逐项检查尤其注意医疗健康类目这几个问题里最值得展开的是跨域和时区这两个。跨域问题在开发阶段就一定会遇到因为开发者工具里的请求源是https://servicewechat.com和后端路径不同请求会被浏览器拦截。SpringBoot解决方式很简单加一个跨域配置类即可。时区问题则是典型的“本地没事、上服务器有事”排查时如果发现所有时间都偏移了整8小时几乎可以确定是时区设置的问题。还有一个小众但容易被问到的坑预约接口返回422而不是500。422通常表示参数校验不通过比如RequestBody接收的JSON字段类型不匹配、必填字段为空等。前端打开控制台查看具体请求参数再和后端实体类字段对比大部分是字段名对不上比如前端传了appointmentDate后端实体字段却是appointment_dateJSON序列化和反序列化的命名策略不一致导致的。6. 这个项目还能怎么扩展如果时间有余力这套疫苗预约系统有不少可以低成本落地的高价值扩展点。消息订阅提醒是最能体现业务思维的一个扩展。微信小程序支持订阅消息用户预约成功时可以弹窗让用户授权订阅“接种提醒”到达预约日期的前一天后端通过定时任务调起订阅消息推送。这个功能技术上不复杂但能帮用户解决实际痛点——很多人预约完就忘了到那天才想起来。做的时候要注意微信订阅消息的一次性授权机制用户每次授权只能发送一条模板消息所以要引导用户在关键节点重新授权。疫苗库存预警也值得做。后台定时任务每小时统计各接种点各时段剩余号源如果某个时段的剩余量低于阈值就给管理员发送站内消息或邮件提醒。这个功能用SpringBoot自带的Scheduled就能实现不需要额外引入消息队列。从“能跑”的角度疫苗预约做到这里已经可以交差了。但如果你想让这个项目在答辩或者面试时更有区分度我建议把精力放在这三件事上一是把并发控制讲清楚从业务风险到技术方案到代码实现形成一个完整闭环二是把安全设计讲清楚包括登录态设计、接口鉴权、敏感信息加密、生产环境配置加固三是把性能优化讲清楚包括数据库索引设计、缓存使用、首屏加载优化。这三件事拿出来任何一个都能体现你和“只会CRUD”之间的差别。前后端分离这个热词其实贯穿了整个项目。SpringBoot只负责提供JSON接口小程序端只负责展示和交互两者通过HTTP协议通信。理解了这条链路以后换任何前端框架都能很快上手。最后再分享一点个人体会。这套“疫苗预约”的课题确实常见但正因为常见评委老师见过的粗糙版本太多了。你不需要把项目做得多么复杂但一定要把主流程的完整度和关键细节的健康度做好。我见过太多人数据库表设计得稀烂预约记录连唯一索引都没加接口一调就重复插入这种项目随便问两句就露馅。把你的表设计理清楚把登录和预约两条主链路的每个步骤写到毫无含糊把并发和安全问题想出一个明确的解决方案这个项目就不只是能过而是能拿得出手。做这个题目的过程中最值得锻炼的也正是这些能力而不是单纯跑通一个Demo。