疫苗预约小程序源码拆包与二次开发实战指南

简介这是一套基于微信小程序的疫苗预约接种系统源码面向需要完成课程设计、毕业设计或二次开发练手的学生与开发者。项目对原有疫苗预约系统进行重构后二次开发采用前后端分离结构导入IDEA后修改pom中的MySQL驱动及application.properties中的数据库与图片路径即可启动运行。系统分为管理员与接种者两端管理员可查看数据分析图并对接种点、医护人员、预约计划、疫苗、接种者信息进行增删改查同时查询支付、预约、签到、预检、接种、留观等历史记录接种者可浏览疫苗与接种点列表、查看预约计划、提交预约申请、模拟支付并查看接种二维码状态。压缩包共644个文件约3.56MB包含86个Java后端源码、115个Vue页面、119个html、86个xml配置及js、scss、sql、properties等资源结构完整。已有1054人学习适合作为小程序与后台管理系统的实战参考。1. 疫苗预约小程序源码拆包从「能跑」到「敢改」的第一道坎上个月帮一个社区卫生服务中心的朋友看他们准备上线的小程序需求很朴素居民能选疫苗、选时段、提交预约、后台能看名单。他们从网上拿了一份「基于微信小程序的疫苗预约接种系统源码.zip」解压之后发现能编译、能点但一改疫苗种类就报错一换数据库就白屏。这不是源码的问题是没人告诉你这套东西的边界在哪。这份资源本质上是一套完整的微信小程序项目实例前端用小程序原生框架写页面和交互后端常见做法是 Node.js 或 Java 提供接口数据落在 MySQL 里。它解决的不是「疫苗怎么打」这种医学问题而是「预约流程怎么在微信生态里跑通」这个工程问题。适合两类人一是课程设计或毕设需要完整业务闭环的学生二是社区、门诊、校医院里想快速搭一个内部预约工具的一线人员。你要的不是从零写而是知道哪几个文件动完就能变成自己的东西。2. 目录结构与技术栈拆解先认清哪块能动、哪块别碰拿到一个 zip 包最忌讳上来就npm install然后跑起来点两下觉得没问题。我一般会先花二十分钟把目录结构和依赖关系画清楚因为后面所有改动都建立在你对「哪些是框架代码、哪些是业务代码」的判断上。这套疫苗预约系统的目录划分通常比较规整但不同来源的包差异很大下面按最常见的结构讲。2.1 前端小程序目录pages 与 utils 的职责边界解压后你会看到一个miniprogram或直接就是小程序根目录里面有app.js、app.json、app.wxss以及pages文件夹。pages下按业务分目录典型的有index首页、appoint预约、record记录、mine个人中心。每个页面四件套.js管逻辑、.wxml管结构、.wxss管样式、.json管页面配置。真正需要你改的九成集中在pages/appoint和utils里。utils通常放request.js请求封装、util.js日期格式化等。请求封装是第一个要看懂的地方因为它决定了后端地址怎么配、token 怎么带。// utils/request.js 常见封装形态 const BASE_URL http://localhost:3000/api; // 改这里指向你的后端 function request(options) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, header: { content-type: application/json, Authorization: wx.getStorageSync(token) || // 登录后存的凭证 }, success: (res) { if (res.statusCode 200) { resolve(res.data); } else { // 401 通常意味着 token 过期需要重新登录 if (res.statusCode 401) { wx.removeStorageSync(token); wx.navigateTo({ url: /pages/login/login }); } reject(res); } }, fail: reject }); }); } module.exports { request, BASE_URL };这段代码的逻辑很直白所有页面调接口都走request统一拼BASE_URL、统一带Authorization。参数上你要关注两个BASE_URL必须改成你实际部署的后端地址本地调试时微信开发者工具要勾选「不校验合法域名」否则localhost会被拦。Authorization的值来自登录后写入缓存的 token如果你后端不用 token 而用 session这里要同步改。2.2 后端接口与数据库三张核心表撑起整个预约流后端不管是用 Express、Koa 还是 Spring Boot核心接口就那么几个登录、疫苗列表、时段查询、提交预约、我的预约。数据库层面三张表基本跑不掉user用户、vaccine疫苗、appointment预约记录。appointment表是重点它通常有user_id、vaccine_id、appoint_date、time_slot、status这几个字段。status字段是业务状态的命门。常见取值是 0 待确认、1 已确认、2 已完成、3 已取消。你改业务时如果新增状态前端所有判断status的地方都要同步否则会出现「后台改了状态、前端显示空白」这种玄学问题。我见过有人把status从数字改成字符串结果列表页的wx:if全部失效排查了一下午。-- appointment 表建表语句MySQL CREATE TABLE appointment ( id int NOT NULL AUTO_INCREMENT, user_id int NOT NULL, vaccine_id int NOT NULL, appoint_date date NOT NULL, time_slot varchar(20) NOT NULL, -- 如 09:00-09:30 status tinyint DEFAULT 0, -- 0待确认 1已确认 2已完成 3已取消 create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user (user_id), KEY idx_date (appoint_date) );建表时我习惯给user_id和appoint_date各加一个索引因为「我的预约」按用户查、「某天名单」按日期查是最频繁的两个操作。time_slot用字符串存是为了前端直接展示如果你要做时段库存扣减建议再加一张slot_stock表否则并发提交时容易超卖。2.3 配置项清单跑起来之前必须改的五个地方很多人卡在「编译通过但接口全挂」八成是配置没改。下面这张表是我每次拿到新包必查的清单按优先级排。配置位置常见键名说明utils/request.jsBASE_URL后端接口根地址本地调试用局域网 IPapp.jsglobalData全局变量有时存了 appid 或环境标识后端.env或config.jsDB_HOST/DB_USER/DB_PASS数据库连接默认值往往是作者本地的后端入口PORT服务端口默认 3000 要和前端对上project.config.jsonappid小程序 appid测试号也能跑改完这五处再在微信开发者工具里点「编译」基本就能看到首页数据了。如果首页是空的但控制台没报错先看 Network 里请求有没有发出去、返回码是不是 200这一步能省掉大量瞎猜。3. 预约核心链路复现从选疫苗到写入数据库跑通首页只是热身真正体现这套源码价值的是预约主链路。这条链路串起来是用户选疫苗 → 选日期 → 选时段 → 填信息 → 提交 → 后端校验 → 写库 → 返回结果。任何一环断了用户看到的就是「点了没反应」。下面按前端交互和后端校验分开讲因为这两块最容易各自为政。3.1 前端选时段与表单提交wxml 数据绑定与校验预约页面的核心是picker组件选日期、自定义按钮组选时段。数据绑定靠data和setData这里有个新手常翻车的点setData是异步的你在它后面立刻读this.data.xxx可能拿到旧值。// pages/appoint/appoint.js 核心逻辑节选 Page({ data: { vaccineList: [], selectedVaccine: null, date: , timeSlot: , name: , phone: }, // 选择疫苗 onSelectVaccine(e) { const id e.currentTarget.dataset.id; const vaccine this.data.vaccineList.find(v v.id id); this.setData({ selectedVaccine: vaccine }); }, // 提交预约 async onSubmit() { const { selectedVaccine, date, timeSlot, name, phone } this.data; // 前端基础校验别省能挡掉八成无效请求 if (!selectedVaccine) return wx.showToast({ title: 请选择疫苗, icon: none }); if (!date || !timeSlot) return wx.showToast({ title: 请选择时段, icon: none }); if (!/^1\d{10}$/.test(phone)) return wx.showToast({ title: 手机号格式不对, icon: none }); try { const res await request({ url: /appointment/create, method: POST, data: { vaccineId: selectedVaccine.id, appointDate: date, timeSlot, name, phone } }); if (res.code 0) { wx.showToast({ title: 预约成功 }); setTimeout(() wx.navigateTo({ url: /pages/record/record }), 1500); } else { wx.showToast({ title: res.msg || 预约失败, icon: none }); } } catch (err) { wx.showToast({ title: 网络异常, icon: none }); } } });逻辑说明onSelectVaccine通过dataset.id拿到点击的疫苗再从列表里找出完整对象存进data这样提交时不用再查一次。onSubmit里前端校验不是可选项手机号正则、必填项判断能挡掉大量脏请求减轻后端压力。参数上vaccineId用数字还是字符串要和后端约定一致我遇到过前端传数字、后端按字符串查导致查不到的血泪经验。3.2 后端接口与并发校验防止同一时段被重复预约后端收到/appointment/create后标准流程是校验参数 → 查该时段是否已满 → 查该用户是否重复预约 → 写库 → 返回。第三步「重复预约」是业务重点同一个用户同一天同一疫苗不该约两次。// 后端 Express 路由示例 router.post(/appointment/create, async (req, res) { const { vaccineId, appointDate, timeSlot, name, phone } req.body; const userId req.userId; // 从 token 解析出来 // 1. 参数校验 if (!vaccineId || !appointDate || !timeSlot) { return res.json({ code: 1, msg: 参数不完整 }); } // 2. 查是否重复预约 const exist await db.query( SELECT id FROM appointment WHERE user_id? AND vaccine_id? AND appoint_date? AND status IN (0,1), [userId, vaccineId, appointDate] ); if (exist.length 0) { return res.json({ code: 2, msg: 您已预约该疫苗请勿重复提交 }); } // 3. 查时段容量假设每时段上限 20 人 const count await db.query( SELECT COUNT(*) AS c FROM appointment WHERE appoint_date? AND time_slot? AND status IN (0,1), [appointDate, timeSlot] ); if (count[0].c 20) { return res.json({ code: 3, msg: 该时段已约满 }); } // 4. 写库 await db.query( INSERT INTO appointment (user_id, vaccine_id, appoint_date, time_slot, status) VALUES (?,?,?,?,0), [userId, vaccineId, appointDate, timeSlot] ); res.json({ code: 0, msg: ok }); });参数说明status IN (0,1)表示只统计「待确认」和「已确认」的记录已取消的不占名额。时段上限 20 是硬编码实际项目里应该从配置表读。这里有个并发坑两个请求同时查到count是 19都判断没满然后都插入结果变成 21。要彻底解决得用事务加行锁或者用 Redis 做原子计数。课程设计级别可以先不做但你要知道这个边界在哪。3.3 联调顺序先接口后页面别反过来我踩过的坑是先在页面上调样式调完发现接口字段对不上又回头改页面。正确顺序是用 Postman 或 curl 把后端每个接口单独跑通确认返回结构再在request.js里配好地址最后才动页面。这样出问题时你能快速定位是接口挂了还是页面逻辑错了。# 用 curl 验证预约接口先拿 token 再提交 curl -X POST http://localhost:3000/api/login \ -H Content-Type: application/json \ -d {code:test_code} # 假设返回 token 为 abc123 curl -X POST http://localhost:3000/api/appointment/create \ -H Content-Type: application/json \ -H Authorization: abc123 \ -d {vaccineId:1,appointDate:2025-06-01,timeSlot:09:00-09:30,name:张三,phone:13800138000}这两条命令能帮你把「接口本身」和「小程序调用」解耦。如果 curl 通了但小程序不通问题一定在BASE_URL、域名校验或请求头如果 curl 就不通别去翻小程序代码先修后端。4. 避坑与排查改这套源码时最容易翻车的五个地方这套源码能跑不代表能改下面五条是我和身边人实际踩过的每条按现象、原因、解决写你对照着排查能省不少时间。现象一首页数据空白控制台无报错。原因通常是BASE_URL还指向作者本地地址或者微信开发者工具没勾「不校验合法域名」。解决打开 Network 面板看请求是否发出、状态码是多少本地调试在「详情 → 本地设置」里勾选不校验域名真机预览必须用 HTTPS 且域名已备案。现象二提交预约提示「参数不完整」但表单明明填了。原因是前端data里的字段名和后端req.body解构的字段名不一致比如前端传vaccineId、后端读vaccine_id。解决在onSubmit里console.log出提交对象和后端接口文档逐字段对命名统一用驼峰或下划线别混用。现象三改了疫苗列表预约页下拉还是旧数据。原因是小程序有缓存wx.setStorageSync存过的列表没清。解决在app.js的onLaunch里加版本号判断版本变了就wx.clearStorageSync()或者调试时手动在开发者工具「存储」面板删掉对应 key。现象四数据库写入成功但「我的预约」查不到。原因是查询条件带了status过滤而新插入的记录status默认值和查询条件不匹配。解决确认appointment表status默认值确认查询 SQL 里的status IN (...)范围我一般会在插入后立刻用相同条件查一次确保能查到。现象五多人同时预约同一时段出现超卖。原因是「查容量」和「插入」之间没有锁并发下都读到未满。解决小规模用事务加SELECT ... FOR UPDATE或者把时段余量放 Redis用DECR原子扣减扣到负数就回滚。课程设计可以不做但生产环境必须处理。提示改任何字段名之前先用全局搜索把前后端所有引用点找出来改一处漏一处是这类项目最常见的翻车方式。5. 二次开发与验证把通用预约改成你单位的专属工具跑通、改通之后这套源码真正的价值在于它能当底座。我一般会做三件事把疫苗数据换成真实品类、把时段规则改成单位实际排班、加一个简单的后台导出。下面说两个最实用的改造点和验证方法。5.1 疫苗品类与时段规则的数据驱动改造原始源码里疫苗列表和时段往往是写死的改起来要动代码。更稳的做法是把它们挪到数据库或配置文件前端只负责渲染。比如建一张vaccine表存名称、描述、适用人群建一张time_slot_config存每天开放的时段。这样运营人员改数据不用碰代码你也不用每次改品类就重新发版。// 改造后时段从接口拉不再写死在页面 async loadTimeSlots(date) { const res await request({ url: /slot/list, data: { date } }); // res.data 形如 [{slot:09:00-09:30, remain:15}, ...] this.setData({ timeSlots: res.data }); }参数说明date传YYYY-MM-DD格式后端按日期查配置表并计算剩余名额。remain为 0 的时段前端置灰不可选这样用户一眼就知道哪些约满了减少无效提交。5.2 验证改造是否成功的三个检查点改完之后别只看页面能点按这三个点验证第一用两个不同账号同时约同一时段最后一名额看是否只有一个成功第二把某个时段remain改成 0看前端是否正确置灰第三导出后台名单核对数据库记录数和页面显示数是否一致。这三点过了基本说明你的改造没有破坏原有业务闭环。检查点操作预期结果并发扣减两账号同时提交最后名额仅一个成功另一个提示约满余量展示手动把 remain 改为 0前端该时段不可点击数据一致性后台导出 vs 数据库 count两边数字相同5.3 一个我常用的调试习惯从那以后我每次拿到这类预约源码都强制先走一遍「接口清单 → 配置清单 → 并发边界」这三步再动任何页面。接口清单确认每个 URL 和字段配置清单确认五处必改项并发边界确认哪些操作会互相影响。这套习惯帮我省掉了大量「改完能跑、上线就崩」的后悔药。希望帮到你。本文还有配套的精品资源点击获取